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Executive  Summary 

We  report  our  results  on  our  research  project,  Human  Systems  Modeling  and  Simulation  (HMS). 
This  project  has  created  new  foundations  for  simulation  studies  of  human  systems.  The  primary 
objectives  of  the  project  have  been  as  follows: 

•  Create  a  major  advance  in  expressive  adequacy  of  fonnal  representations  of  human 
systems.  Treat  not  only  the  physical  properties  and  motion  dynamics  of  human 
systems,  but  also  and  primarily  the  cognitive  and  social  inter-dependencies  that 
underwrite  human  behavior. 

•  Develop  technology  for  the  computational  specification  of  human  systems,  based  on 
the  foregoing.  Create  human-systems  scenarios  to  test  this  technology. 

•  Train  AFRL-selected  staff  in  Practice  Mapping.  Assist  trainees  in  the  mapping  of  an 
AFRL-selected  organization,  and  the  creation  of  valid  human-systems  models  for 
elements  of  the  selected  partner  organization.  Support  the  trainee’s  development  of 
simulation  studies  relevant  to  the  mission  or  self-understanding  of  the  organizational 
partner. 

Our  work  is  described  in  detail  in  the  sequel.  Here,  we  summarize  how  we  have  accomplished 
each  objective. 

Entering  this  project,  we  had  previously  specified  practices,  adaptive  behavior  generators,  in 
tenns  of  what  we  now  call  the  Practice  Proposition,  “In  Situation  S,  Do  Activity  A  to  Enforce 
Criteria  C.”  We  had  proposed  that  a  computational  analogue,  now  called  the  Practice  Schema, 
could  be  developed  based  on  the  idea  of  monitoring  criteria-relevant  conditions  and  directing 
computation  accordingly. 

We  have  now  fully  specified  Practice  Schemata.  We  describe  them  informally  as:  “Monitor  for 
Conditions  C  in  Situation  S  and  Adjust  the  Execution  of  Activity  A  to  Obviate  C”.  In  other 
words,  criteria  are  served  by  monitoring  for  some  conditions  that  reveal  the  criteria  are  not 
satisfied,  then  acting  to  eliminate  or  make  irrelevant  the  criteria.  When  this  occurs,  the  monitor  is 
satisfied,  and  the  practice  is  quiescent  (suspends  successfully,  or  fails). 
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We  describe  Practice  Schemata  formally  in  terms  of  a  language  specification  we  developed 
and  report  on  here,  called  the  “Quasi-Executable  Practice  Specification  Language.”  This 
rigorous  computational  formalism1  defines  the  syntax  and  semantics  for  specifying  a  practice 
schema’s  three  components:  an  information  environment  (the  situations  created  by  and  relevant 
to  the  practice),  an  activity  generator  (the  advisable  procedural  content  of  the  practice)  ,  and  a  set 
of  monitors  (the  tests  that  detennine  whether  execution  needs  to  be  adjusted  and  if  so,  that 
suspend  and  restart  the  activity  generator  with  new  instructions.  Triggering  (i.e.,  initiation  of  a 
practice)  is  accomplished  by  monitors  -  behavior  is  in  response  to  the  failure  of  criteria. 

We  refer  to  the  specification  as  a  “quasi-executable”  language  because  we  aim  to  support 
simulation  of  human  systems,  within  a  variety  of  existing  and  to-be-developed  simulation 
systems.  It  is  beyond  the  scope  of  this  project  to  develop  a  simulation  environment  or  driver,  or 
even,  to  forge  the  link  between  our  formal  specification  and  any  particular  environment  or 
driver.  The  quasi-executable  specification  is  complete  with  respect  to  the  requirements  of  a 
practice,  and  a  simulation  driver  could  certainly  be  developed  to  manage  simulation  over  a  set  of 
practices  -  i.e.,  practices  defined  in  this  language  will  execute  if  and  once  such  a  driver  is  built. 
However,  the  requirement  for  this  project  has  been  to  sufficiently  specify  practices,  in 
computational  form,  so  that  they  can  be  translated  into  a  form  compatible  with  the  native 
commitments  of  suitable  existing  simulation  environments.  We  have  achieved  this. 

In  addition  to  the  representational  commitments  of  simulation  environments,  there  are 
generally  a  host  of  other  commitments  having  to  do  with  expectations  for  the  kinds  of  behavior 
to  be  simulated,  and  the  kinds  of  studies/experiments  to  be  conducted.  For  example,  most 
simulation  environments  focus  on  the  physical  realization  of  actor  state  (i.e.,  location,  resources, 
other  properties).  Actor  behavior  is  often  simplified  to  state  transition  (e.g.,  motion  dynamics). 
Interaction  (engagements)  of  actors  in  these  simulations  is  not  often  modeled.  Rather,  a 
constructive  model  of  the  process  is  replaced  with  (perhaps  complex)  functions  that  determine 
the  outcome  of  the  interaction  directly  -  e.g.,  as  a  function  of  the  physical  configuration  of  the 
participants  (the  opposition  of  their  states).  For  example,  such  environments  have  inter-visibility 


1  Independently  of  this  project,  a  fully  algebraic  formalization  of  Generative  Practice  Theory  -  and  so  for  practices  and  actors  - 
has  been  developed  in  the  Pi  Calculus.  This  work  was  a  PhD  dissertation  (Stroh,  2004)  at  Stanford,  supervised  by  Dr.  Michael 
Fehling. 
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calculations  that  determine  whether,  when,  and  how  actors  may  see  one  another’s  emanations.  A 
simulation  environment  of  this  form  might  then  favor  experiments  that  focus  on  motion  and 
compute  results  of  engagements  via  attrition  models. 

Hence  translation  from  quasi-executable  practice  schemata  to  the  native  form  of  a  particular 
simulator  entails  not  just  reformatting  (aligning  representation)  but  also  restriction  to  the  range 
of  behavior  and  experiment  types  expressible  in  the  target  simulation  environment. 

This  means  that  there  is  a  great  deal  about  human  system  behavior  that  we  can  now  express  in 
our  quasi-executable  language,  but  that  standard  environments  cannot  fully  exploit.  Ideally,  a 
simulation  driver  can  be  developed  to  run  our  models  as  fully  specified.  Until  then,  we  find  there 
is  still  great  value  in  developing  our  models  and  converting  them  to  more  restrictive  simulation 
environments.  For  example,  we  may  model  the  risk  attitude  of  an  actor  -  a  personality  feature  of 
that  actor  -  and  specify  how  the  actor’s  current  assessment  of  the  proximity  and  severity  of 
perceived  threats  affects  the  propensity  to  hide  out  versus  move  (depicted  parametrically).  In 
other  words,  a  motion-dynamics-oriented  simulation  environment  can  still  enjoy  benefits  of  a 
validated  model  of  an  actor’s  personality,  even  if  the  simulation  experiment  cannot  treat  that 
personality  directly. 

In  addition  to  this  practice  specification  language,  we  developed  and  through  several  iterations 
refined  an  actor  architecture,  called  the  “Ambiguity  Reduction  Architecture.”  The  Ambiguity 
Reduction  Architecture  (ARA)  establishes  the  mechanism  for  practices  to  control  one  another. 
Whereas  the  practice  provides  for  adaptation  at  the  level  of  a  given  set  of  criteria,  the  ARA 
provides  for  adaptation  across  practices.  In  this  way  the  actor  (i.e.,  not  just  the  practice)  can 
intervene  on  its  behavior  as  needed  -  as  external  conditions  require,  to  resolve  problems  prior  to 
continuing,  to  do  something  more  important,  etc. 

The  ARA  is  based  on  the  recognition  that  there  will  often  be  conflicts  among  practices  that 
need  to  be  resolved  -  and  therefore,  ambiguity  about  ‘what  to  do  next.  ’  These  conflicts  arise  due 
to  the  inconsistency  of  practices  (incompatible  or  context-specific  learning  trajectories  lead  to 
incompatibility),  the  lack  of  enabling  resources  for  otherwise-mandated  practices,  or  due  to  the 
finite  cognitive  capacity  any  actor.  In  each  case,  the  ARA  provides  for  suspending  conflicting 
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practices,  or  recognizing  patterns  of  suspended  practices  that  need  to  be  resolved,  and 
developing  and  legislating  a  resolution. 

Ambiguity  reduction  is  just  another  kind  of  practice  -  in  situation  S  (conflict),  do  activity  A 
(resolution  procedure)  to  enforce  criteria  C  (prevent/maintain/achieve  what  is  most  worthwhile 
in  this  situation  of  conflict).  As  such,  the  ARA  provides  that  some  practices  will  be  supervisory 
with  respect  to  others.  This  means  that  they  will  compute  mostly  over  execution  state  of  other 
practices,  and  their  effect  will  be  to  resolve  problems  of  execution  state. 

In  the  final  version  of  the  ARA,  we  distinguish  four  categories  of  practices:  Reactive, 
Knowledge,  Execution,  and  Deliberative.  Reactive  practices  are  sensor  practices  (i.e.,  ‘drivers’) 
and  control  practices  that  resolve  ambiguity  and  otherwise  manage  these.  Execution  practices  are 
effector-drivers  and  control  practices  that  supervise  them.  Knowledge  practices  are  those  that 
couple  the  reactive  and  execution  practices,  along  with  their  associated  supervisory  practices 
(i.e.,  those  that  resolve  ambiguities  by  executing  a  pre-existing  method,  as  a  choice  or  policy). 
Finally,  Deliberative  practices  are  higher-level  practices  that  form  new  ambiguity  reduction 
methods  and  enter  them  as  supervisorial  with  respect  to  other  practices.  Each  category  of 
practice  is  specifically  identified  with  resources,  e.g.,  sensors,  tools,  and  cognitive  capacity. 

Practices  may  contain  other  practices  as  constituents.  Therefore,  the  ARA  may  model  (enables 
a  modeler  to  specify)  an  individual  human  being,  or  any  collective  whose  practices  are  inter¬ 
dependent.  For  example,  if  an  individual  (or  a  team)  is  gathering  information,  they  may  function 
as  a  Reactive  practice  within  the  ARA.  Similarly,  the  actor  (individual  or  social)  that  implements 
a  COA  is  encapsulated  as  an  Execution  practice. 

We  prototyped  technology  to  specify  Practice  Propositions,  Practice  Schemata,  and  Actors.  We 
describe  these  in  the  sections  to  follow.  We  integrated  this  fully  within  our  ACCORD 
environment.  Hence  the  new  tools  inter-operate  with  the  extensive  technology  we  have 
developed  to  gather  and  fonnalize  data  on  human  behavior.  In  addition,  we  have  developed  (on 
other  work)  a  Windows-based  and  a  Java-based  API  to  enable  other  technologies  to  inter-operate 
with  ACCORD.  Therefore,  we  have  developed  the  necessary  technology  to  deliver  quasi¬ 
executable  human-systems  models. 
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We  are  delivering  the  technology  prototyped  on  this  contract  within  the  complete  ACCORD 
environment.  Hence  we  are  delivering  the  tools  that  support  specification  of  computational 
models  of  human  systems,  along  with  the  most  recent  versions  of  all  other  tools,  including  those 
developed  on  other  projects”. 

We  conducted  a  substantial  amount  of  scenario  development  work,  to  test  the  quasi-executable 
specification  and  our  practice  and  actor  specification  technologies.  One  scenario  is  a  moderately 
detailed  mapping  study  in  which  a  Key  Figure  is  seeking  to  escape  to  safe  haven.  We  do  not  see 
this  individual,  but  we  see  the  effects  of  his  behavior  on  others.  This  scenario  emphasizes  the 
capture  and  formalization  of  data  (100  days  of  message  traffic  on  our  pursuit  of  him),  and  then 
the  methods  that  lead  to  discovery  and  articulation  of  practices  of  that  actor.  In  this  scenario,  our 
emphasis  has  been  to  illustrate  the  overall  disciplines  of  mapping  (gathering  data,  creating  a 
suitable  ontology,  formalizing  in  event-behavior  graphs)  modeling  (creating  practice  and  actor 
models),  and  analysis  (introducing  forecasts  into  the  evolving  event-behavior  graph). 

We  also  invented  a  multi-actor  case  study,  this  time  to  support  a  comprehensive  simulation 
study.  We  developed  all  of  the  practices  of  all  of  the  actors  sufficiently  to  provide  for  actor 
sensing  (self  and  others),  deliberation,  behavior,  and  joint  (interactive)  behavior.  This  scenario  is 
also  based  on  a  manhunt  -  a  narcotics  trafficker  seeks  to  escape  to  safe  haven. 

We  specified  the  latter  case  study,  the  actors  and  their  practices,  using  our  quasi-executable 
language  specification,  and  embedded  in  the  tools  for  the  ambiguity  reduction  architecture.  We 
are  delivering  this  case  study  as  a  project  within  ACCORD.  We  also  specify  the  independent 
variables  and  so  the  range  of  potential  simulation  studies/experiments  that  might  be  run. 


2  AFRL  funded  an  allied  project,  now  completed,  to  create  elements  of  simulation  support  needed  to  manage  the  actor  models 
and  simulation  studies  that  this  project  provides  for.  We  report  those  results  separately.  In  summary,  we: 

•  developed  a  formal  foundation  to  characterize  the  uncertainty  of  a  model  of  an  actor  (as  a  function  of  uncertainty  in 
practice  models,  and  thus  on  the  evidence  and  assumptions  that  warrant  the  models) 

•  developed  technology  to  manage  ‘releases’  of  practice  and  actor  models  (users  publish  a  model  that  is  fully  linked  to 
its  evidential  and  assumptive  foundations;  models  are  maintained  in  a  history  and  browseable) 

•  developed  the  necessary  indexing  scheme  to  manage  a  collection  of  related  simulation  studies  (and  so  specify 
independent  variable  bindings,  actor  model  version,  and  dependent  measures). 
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We  conducted  a  variety  of  training  initiatives  on  this  contract.  Early  in  the  project,  we 
produced  a  book-length  monograph  on  Practice  Mapping  methodology,  and  delivered  it  to 
AFRL. 

We  invented  and  prototyped  a  new  tool,  called  the  Journal  tool,  to  guide  trainees  in  Practice 
Mapping  to  become  more  careful  about  their  observations,  and  to  begin  to  make  important 
cognitive  and  methodological  distinctions.  The  trainee  made  use  of  this  method,  and  his  results 
supported  extensive  methodological  training  based  on  the  human-system  activity  he  observed. 

We  developed  a  comprehensive  curriculum  for  trainees.  This  curriculum  includes  background 
studies  in  Decision  Theory,  extensive  exercises  to  leam  Generative  Practice  Theory  by  working 
concrete  examples  (using  Synergia-supplied  data),  and  guidance  for  mapping  the  practices  and 
organizational  structure  of  a  partner  organization  (e.g.,  an  Air  Force  planning  or  mission 
management  component). 

We  spent  two  days  with  the  trainee,  presenting  Generative  Practice  Theory  (GPT)  and  the 
Practice  Mapping  (PM)  methodology.  We  also  worked  with  the  trainee  on  a  collection  of 
exercises  we  designed  and  he  worked  on,  prior  to  joining  us  for  GPT  and  PM  training. 

After  this,  we  conducted  ongoing  training,  following  our  usual  methods.  We  reviewed  trainee 
products  on  exercises.  We  provided  extensive  instruction  in  GPT  and  PM,  in  the  fonn  of 
critiques,  extensions,  and  instruction  on  the  trainee’s  submissions.  The  curriculum,  and  a  sample 
exercise  and  associated  Synergia  instruction  appear  in  this  report. 

We  delivered  a  copy  of  ACCORD  to  the  trainee,  to  practice  with,  and  in  preparation  for  that 
trainee  to  map  an  organization  of  interest. 

AFRL  leadership  worked  repeatedly  over  the  life  of  this  project  to  identify  a  suitable 
organization  to  map  (e.g.,  a  part  of  a  JFACC),  and  this  formed  a  topic  of  discussion  at  each 
meeting.  Synergia  supported  this  activity  by  gathering  material  and  learning  what  we  could 
about  each  candidate  identified  by  AFRL,  and  evaluating  mapping  requirements  should  that 
candidate  agree  to  participate.  Synergia  also  identified,  contacted,  and  attempted  to  engage 
suitable  Air  Force  partners  (e.g.,  Checkmate,  Air  Force  Studies  &  Analysis  Agency).  For  these 
Synergia-developed  candidates,  AFRL  visited  senior  staff  in  the  Pentagon  on  our  behalf. 
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However,  for  a  variety  of  reasons,  including  complexity  of  candidate  organizations,  ongoing 
reorganization  initiatives,  strong  conflicting  demands  (due  to  the  ongoing  missions  in 
Afghanistan  and  Iraq),  and  the  lack  of  any  mandate  requiring  those  organizations  to  participate, 
an  organization  willing  to  serve  as  a  partner  on  this  work  was  never  identified.  Hence  the  trainee 
did  not  map  an  existing  organization. 

Given  the  lack  of  a  partner  organization  on  which  to  base  mapping  and  then  simulation  studies, 
AFRL  ultimately  decided  to  have  the  trainee  focus  on  learning  the  JSAF  simulation 
environment.  Once  we  learned  of  this  decision,  we  reorganized  our  effort  to  produce  the  most 
extensive  simulation  study  we  could  accomplish  on  our  own.  We  concentrated  on  the 
development  of  the  latter  simulation  case,  and  ensured  that  it  fully  exercised  the  actor 
architecture  -  in  particular,  requiring  close  coupling  among  sensor,  knowledge,  and  execution 
practices,  within  and  across  actors.  Given  the  selection  of  JSAF,  we  chose  to  produce  a 
simulation  exercise  with  significant  motion-based  content.  We  fully  specified  the  actor  models  in 
quasi-executable  form,  and  are  delivering  them  in  this  report  and  as  an  ACCORD  library.  We  are 
confident  that  this  modeling  exercise  underwrites  useful  and  interesting  investigations  of  quasi¬ 
executable  human-system  simulation,  and  we  look  forward  to  future  work  with  AFRL,  in  which 
we  would  advise  on  and  pursue  such  investigations. 

The  sections  that  follow  present  detailed  results  on  the  quasi-executable  practice  specification 
language,  actor  architecture,  and  training.  For  a  review  of  the  theoretical  foundation  provided  by 
Generative  Practice  Theory,  please  see  Appendix  A.  Appendix  B  contains  a  sample  practice 
from  the  first  scenario,  and  Appendix  C  the  simulation  specification  for  the  second  case  study  we 
invented  (also  delivered  within  ACCORD). 


7 


1.  Quasi-Executable  Specification  Of  Human  Systems  as  Systems  of 
Practices 

We  present  an  overview  of  practice  schemata  and  their  intended  fonn  of  execution.  Next  we 
describe  the  formal  specification  of  the  computational  form  of  practices,  namely,  “practice 
schemata”.  Then  we  describe  the  actor  architecture  we  designed,  so  that  individual  and  social 
actors  can  be  implemented  as  collections  of  interdependent  practices.  We  implemented  an 
interface  to  support  the  definition  of  practices,  and  the  basic  actor  architecture  on  this  contract  - 
the  ability  to  assemble  individual  actors  as  systems  of  practices,  assigning  the  practices  as  one 
of:  sensory,  base,  supervisory,  and  effector.3 

We  now  turn  to  the  practice  construct.  Recall  than  an  actor  is  a  system  of  practices,  which  is  a 
practice.  Hence  this  construct  can  be  read  as  the  generative  capacity  for  skills,  individuals,  and 
social  fonnations. 

Practice  Schema 

A  practice  schema  is  a  computational  model  of  a  practice.  Recall  that  a  practice  is  defined  by 
the  proposition:  In  Situation  S,  Do  Activity  A  to  Enforce  Criteria  C. 

A  practice  schema  is  composed  of  an  infonnation  environment,  a  set  of  activity  generators,  and 
a  set  of  monitors. 

The  function  of  a  practice  schema  is  to  generate  a  computational  image  of  a  behavior  -  a 
computational  trace  that  models  human  behavior  as  responding  to  initiating  and  in-process 
events,  and  strives  to  enforce  criteria  associated  with  that  practice. 

Criteria  are  not  explicitly  reified  in  practice  schemata  -  there  is  not  a  component  that  contains 
the  criterion.  Instead  behavior  is  shaped  by  the  infonnation,  activity  generator,  and  monitors  so 
that  the  criteria  tend  to  be  enforced.  (Criteria  are  enforced  if  conditions  pennit,  and  so  long  as 
more  important  criteria  do  not  intervene).  Typically,  a  practice  has  some  reference  for  what 
counts  as  good  or  better,  and  behavior  is  managed  by  monitoring  for  conditions  that  indicate  the 


3  We  are  developing  the  structures  that  enable  formalization  of  actor  interdependencies  on  another  contract;  a  first  version  is  in 
place. 
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reference  is  unmet  and  then  signaling  the  activity  generator  to  compensate  -  with  the  signal 
reflecting  the  type  and  scale  of  the  error  (departure  from  the  reference).  We  often  call  the 
reference  a  “governing  variable.” 


We  show  a  sample  practice  schema  here,  within  ACCORD.  Note  the  separate  definition  of 
situation,  activity,  and  criteria  (monitors),  the  maintenance  of  ancestor,  descendant,  and  variant 
practices,  and  the  evidence  and  rationale  that  warrant  this  new  model  of  the  practice. 


0  Syneria  ~  Practice  Palette  o*  0*  IEI 

Actor:  Key  Figure  Name:  EscapeToSafeHaven  Date:  10-23-2003  12:41:46 

When  in  the  following  SITUATION: 

Maintain  view  of  troops,  assets,  self-location,  and  threat  to  self  safety 


Situation  Variables 

o  Activity  e  { encamped,  in-transit } 
o  CurrentLocation 

o  ThreatState  =  Threatlntensity  X  TimeToThreatAppearance 

□  Threatlntensity  e  { none,  low,  medium,  high } 

□  TimeToThreatAppearance  e  { unknown,  days,  hours,  imminent} 

o  EncampmentSites  e  {Settlement  A,  Settlement  B,  Settlement  C,  CaveComplex  I,  CaveComplex  II,  CaveComplex  III,  CaveComplex  IV} 
Resource  Variables 

o  Vehicle  e  { car,  truck, ...} 

o  Weapons  e  {  small  arms,  SLMs,  weaponized  sarin} 

Allied  Actors 

o  TroopStrength  =  TroopQuality  X  TroopNumbers 

□  TroopQuality  e  { low-quality,  medium-quality,  high-quality } 

□  TroopNumbers  e  { #LQ,  #MQ,  #HQ } 
o  StayBehindStrength  c  TroopStrength 

Initiator 

o  (AND  ( Activity  =  encamped)  (Threatlntensity  *  none)) 


Undertake  the  following  ACTIONS: 

L  eave  behind  a  die-in-place  (sacrificial)  unit,  with  skills,  numbers,  and  resources  minimally  sufficient  to  enable  escape  to  selected  destination  (safe  haven) 

(PROG  (EscapeDifficulty ,  TroopStrength,  SafeHaven) 

[PRACTICE  DetermineSafeHaven  (CurrentLocation,  TroopStrength,  TimeToThreatAppearance)  ] 

[PRACTICE  FormActor  (EscapeDifficulty,  TroopStrength) 

StayBehindStrength  StayBehindResources 
TroopStrength  c  TroopStrength  -  StayBehindStrength 
Resources  Resources  \  StayBehindResources] 

[PRACTICE  CollectRemainingTroops  (TroopStrength)  ] 

[PRACTICE  Exit  (SafeHaven)  ] ) 


So  as  to  enforce  CRITERIA: 

Continuously  monitor  self  activity,  threat  intensity,  and  time  to  threat  appearance;  compute  difficulty  of  escape,  which  will  determine  tire  type  of  force  and  weapons  to  be  sacrificed 

Criterial  Variables 

o  EscapeDifficulty  e  {  negligible,  low,  medium,  high  } 

Monitored  Varibles 
o  Activity 
o  Threatlntensity 
o  TimeToThreatAppearance 

Local  Inferences 

o  (OR  (  (Threatlntensity  =  high)  (AND  (Threatlntensity  =  medium)  (OR  (TimeToThreatAppearance  =  imminent)  (TimeToThreatAppearance  =  hours)))))  ^  EscapeDifficulty  =  high 
o  (OR  (  AND  ( (Threatlntensity  =  medium)  (OR  (TimeToThreatAppearance  =  unknown)  (TimeToThreatAppearance  =  days))))  =>  EscapeDifficulty  =  medium 
o  (AND  (Threatlntensity  =  low)  (TimeToThreatAppearance  =  days))  =>  EscapeDifficulty  =  low 

o  (OR  (Threatlntensity  =  none)  (AND  (Threatlntensity  =  low)  (TimeToThreatAppearance  =  unknown)))  =>  EscapeDifficulty  =  negligible 

Edit  Close 


Practice  History 


10-20-2003  12:41:31 
10-5-2003  12:40:33 
9  22  2003  12:37:13 
8-22-2003  12:25:47 
7-10-2003  12:23:21 
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Information  Environment 


The  Information  Environment  is  defined  by  a  list  of  variables,  and  their  domains,  that 
influence  the  practice.  Some  variables  are  internally  generated;  others  are  communicated  from 
other  (external)  practices. 

The  information  environment  may  save  state  as  a  result  of  execution,  accessible  under  future 
execution  -  as  when  a  behavior  recurs  or  is  suspended  and  restarted,  and  the  later  execution 
depends  on  elements  of  the  prior  one. 

Monitors  compute  over  the  contents  of  the  infonnation  environment. 

Activity  Generator 

The  Activity  Generator  is  a  set  of  five  functions,  initialize,  main,  pause,  resume,  and  kill,  used 
to  describe  the  actions  taken  by  an  actor  to  enforce  certain  criteria.  The  bodies  of  each  of  these 
functions  are  defined  using  the  language  constructs  and  basic  data  types  described  in  our 
language  definition. 

The  initialize  function  is  used  to  set  the  internal  variables  of  the  practice,  which  are  used  by  the 
Activity  Generator’s  main  function. 

The  main  function  is  the  definition  of  the  action  steps  executed  by  the  actor.  This  function  is 
not  only  comprised  of  our  language  constructs  and  basic  data  types  as  mentioned  before,  it  can 
also  contain  references  to  other  practices.  This  function  is  invoked  by  monitors  when  they 
establish  that  certain  criteria  are  not  being  met. 

Note  that  the  main  function  may  embody  parallel  generators,  and  also  may  embed  a  set  of 
practices.  It  is  not  limited  to  being  a  single  function. 

The  pause  function  is  used  to  interrupt  the  Activity  Generator’s  main  function.  This  function 
stores  its  variables’  states,  as  well  as  the  point  in  the  function  at  which  it  was  paused. 

The  resume  function  is  used  to  restart  the  Activity  Generator’s  main  function  at  the  point  it 
was  paused.  It  uses  the  information  that  was  stored  by  the  function  pause  to  do  so. 

The  kill  function  is  used  to  terminate  the  Activity  Generator’s  main  function  before  its  natural 
completion.  It  allows  the  user  to  define  the  proper  tenninating  procedure  steps  to  take. 
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Monitors 


Monitors  consist  of: 

•  a  list  of  variables  (the  “event  list”)  that  are  monitored  for  changes, 

•  a  specified  condition  on  those  variables  (the  “decision  schema”),  and 

•  a  procedure  body  that  accomplishes  the  control  action  that  advises  or  redirects  activity 
generators. 

Monitors  may  have  the  form  of  busy-wait  tests,  those  that  are  active  while  monitoring,  and 
may  also  have  the  form  of  non-busy-wait  tests,  those  that  are  not  active  while  monitoring  for  the 
lack  of  satisfaction  of  criteria. 

The  event  list  may  consist  of  variables  communicated  from  outside  of  the  practice,  internally- 
generated  variables,  or  both.  However,  regardless  of  the  source,  the  information  is  within  the 
information  environment  of  this  practice. 

The  decision  schema  generally  tests  “while”  and  “when”  conditions  on  instances  of  the  event 
list  (subsets  of  the  domains  defined  for  those  variables,  i.e.,  specific  bindings).  The  decision 
schema  may  compose  tests  according  to  logical  operators. 

The  procedure  body  is  comprised  of  our  language  constructs,  basic  data  types,  and  references 
to  practice  Activity  Generators.  It  may  have  the  fonn  of  a  case  statement,  selecting  among  or 
otherwise  organizing  the  ensuing  activity  generators. 

As  the  monitored  variables  change,  they  are  compared  to  the  decision  schema.  Positive 
matches  launch  the  procedure  body  of  the  monitor,  which  interrupts  execution  of  an  activity 
generator  and  may  then  launch  other  activity  generators,  or  relaunch  the  first  one,  under 
specified  conditions.  These  ‘return  conditions’  are  determined  as  a  function  of  the  evaluated 
decision  schema. 

Summary  of  Practice  Execution: 

Practices  are  generators  that  exist  to  satisfy  actor  criteria. 
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Practices  are  controlled  by  monitors.  Monitors  test  for  evidence  of  failure  to  satisfy  criteria.  If 
so,  they  launch,  suspend,  or  redirect  computation  to  reify  an  actor’s  method  of  managing 
(adapting)  behavior.  Note  that  initiation  of  the  practice  is  just  another  instance  of  monitoring. 

Monitors  may  test  directly  for  criterial  satisfaction,  or  they  may  test  conditions  that  imply 
something  about  criterial  satisfaction.  It  is  the  responsibility  of  the  activity  generator  to  (strive 
to)  repair  the  deviation  from  desired  criteria. 

When  monitors  detect  changes  in  the  states  of  variables  they  are  monitoring,  they  evaluate  the 
decision  schema  -  to  determine  whether  a  change  in  the  activation  or  execution  status  of  activity 
generators  is  warranted.  If  so,  they  modify  the  appropriate  execution  status  of  the  relevant 
activity  generator(s).  Note  they  can  only  operate  on  the  execution  trace  ‘so  far’;  monitors  cannot 
redirect  execution  to  registers  corresponding  to  future  (not  yet  effected)  computation. 

Concurrent  with  the  process  of  procedure  execution  within  activity  generators,  monitored 
variables  may  change.  This  may  occur  as  a  consequence  of  procedure  execution,  or  due  to 
external  influence.  These  changes  may  create  the  need  to  interrupt  and  redirect  the  activity 
generator. 

This  interrupt  and  redirect  protocol  is  accomplished  by  a  form  of  continuation.  It  uses  the 
pause  and  resume  functions:  the  main  procedure  is  temporarily  paused  to  allow  the  monitor  to 
determine  (via  its  procedure  body)  how  to  redirect  computation.  This  may  await  changes  in 
conditions  created  externally  or  via  other  practices.  It  may  resume  from  the  point  at  which  it  was 
paused,  or  from  an  earlier  point.  It  may  use  any  information  in  the  infonnation  environment  that 
has  occurred  prior  to  and  during  the  pause,  as  well  as  information  created  via  execution  thusfar. 
Pause  can  also  lead  to  termination:  the  main  procedure  is  aborted.  This  is  done  with  a  call  to  the 
kill  function.  Kill  stops  the  main  procedure,  does  some  final  steps,  and  then  exits. 

Program  debuggers  offer  a  useful  analogy  to  practice  execution.  Once  the  debugger  is 
launched  it  lives  in  the  background  monitoring  for  problems  in  the  execution  of  a  program.  If  a 
problem  is  detected  it  interrupts  the  program,  does  the  work  it  needs  to  do  to  display  errors  and 
allow  the  user  to  make  changes  to  the  program,  and  then  lets  the  program  resume  were  it  was 
interrupted.  This  is  analogous  to  concurrent  execution  of  monitors  that  may  pause  ongoing 
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execution  of  an  activity  generator  and  then  terminate  it,  or  resume  it  at  an  earlier  point  and  with 
revised  state  information. 


1.1  Computational  Specification  of  Practice  Schemata 

We  present  the  fonnal  specification  language  for  quasi-executable  practice  schemata. 


1.  BASIC  DATA  TYPES: 

TYPE  =  {  Integer,  Real,  Boolean,  String  }  u  SET_NAMES 

2.  KEYWORDS: 

if,  else,  par,  [when],  while,  break,  continue,  {,  },  return,  Integer,  Real,  Boolean, 
String,  set,  &&,  ||,  setdiff,  subset,  void,  activitygen,  monitor,  practice,  typegen 

3.  LANGUAGE  CONSTRUCTS 

Triggering_Event_List  :=  (  s  |  TYPE  var_name  [,  TYPE  var_name]*  ) 

IF  :=  if  CONDITION  {  ([, ACTION\+ )  } 

IF-ELSE  :=  IF  else  (  [IF-ELSE]  |  s  )  ACTION 

WHEN  :=  when  CONDITION  {  ([, ACTION\+ )  } 

PAR  :=  (if  CONDITION  |  when  CONDITION)  par  { Action-1  . . .  Action-n  } 
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ACTION  :=  (  Block_Of_Code  |  activityGen_name  )* 

AND  :=  CONDITION  &&  CONDITION 

OR  :=  CONDITION  ||  CONDITION 

COMPARISON_OP  :=  <,  <=  >  >=,  =,  != 

COMPARISON  :=  (var_name  |  VALUE)  COMPARISON_OP  (var_name  |  VALUE) 
ARITHMETIC_OP  :=  +  |  - 1  *  |  / 

ARITHMETIC  :=  (var_name  |  VALUE)  ARITHMETIC_OP  (var_name  |  VALUE) 

WHILE  :=  while  CONDITION  {  ([> ACTION\+ )  } 

SETDIFF  :=  dest_set  :=  first_set  setdiff  second_set 

/*  text  7  traditional  comment 

//  text  end-of-line  comment 

4.  INFORMATION  ENVIRONMENT 

Set  Declaration: 

set  set_name  =  {  elem-1,  elem-2,  elem-n  }; 

Variable  Declaration: 

TYPE  var_name; 
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Variable  Assignment: 
var_name  :=  <VALUE>\ 

SubSet  Declaration: 

subset  set_name  :  another_set_name; 

5.  ACTIVITY  GENERATOR 


activitygen  activityGen_name(  Triggering_Event_List) 

{ 

PARAMETER_LIST_REFERENCES; 

PARAMETER_LIST_COPY; 

void  lnitialize(PARAMETER_LIST) 

{ 

<initialize  PARAMETER_LIST_REFERENCES> 
initialize  PARAMETER_LIST_COPY> 

} 

void  Main() 

{ 

<Procedure_Body> 

} 

void  Pause() 

{ 

<Procedure_Body> 

} 

void  Resume() 

{ 
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<Procedure_Body> 


} 

void  Kill() 

{ 

<Procedure_Body> 

} 

} 

6.  PROCEDURE 


<return_type>  proc_name([PARAMETER_LIST]) 

{ 

[Built-up  from  language  constructs] 
[LOCAL_VARS] 

[PROCEDURE_CALLS] 

[PRACTICE_REFERENCES] 

} 

7.  MONITOR 


monitor  monitor_name(Trigger_list) 

{ 

while  (true) 

{ 

if  ( CONDITION ) 

activityGen_name.<method_name> 
else  if  ( CONDITION ) 

activityGen  _name.<method_name> 
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else 


} 


activityGen  _name.<method_name> 


8.  PRACTICE  SCHEMA 


practice  practice_name 

{ 

[INFO_ENV\ 

([MONITORS]*) 

([, ACTIVITY_GENS ]*) 


9.  TYPE  GENERATOR 


typegen  type_name  =  { first_element,  generator_function  } 


10.  GENERATOR  FUNCTION 


type_name  generator() 

{ 

return  <expression> 

} 
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1.2  Actor  Architecture 

Synergia  invented  our  actor  architecture,  called  the  “Ambiguity  Reduction  Architecture,”  prior 
to  this  contract.  For  this  project,  we  critically  reviewed  its  contents,  made  a  collection  of 
improvements,  and  implemented  a  first  version  within  our  ACCORD  technology. 

The  Ambiguity  Reduction  Architecture  (ARA)  establishes  the  mechanism  for  practices  to 
control  one  another.  Whereas  the  practice  provides  for  adaptation  at  the  level  of  a  given  set  of 
criteria,  the  ARA  provides  for  adaptation  across  criteria.  In  this  way  the  actor  can  intervene  on 
its  behavior  as  needed  -  as  external  conditions  require  too  resolve  problems  prior  to  continuing, 
to  do  something  more  important,  etc. 

The  ARA  is  based  on  the  recognition  that  there  will  often  be  conflicts  among  practices  that 
need  to  be  resolved  -  and  therefore,  ambiguity  about  ‘what  to  do  next.  ’  These  conflicts  arise  due 
to  the  inconsistency  of  practices  (incompatible  or  context-specific  learning  trajectories  lead  to 
incompatibility),  the  lack  of  enabling  resources  for  otherwise-mandated  practices,  or  due  to  the 
finite  cognitive  capacity  any  actor.  In  each  case,  the  ARA  provides  for  suspending  conflicting 
practices,  or  recognizing  patterns  of  suspended  practices  that  need  to  be  resolved,  and 
developing  and  legislating  a  resolution. 

Ambiguity  reduction  is  just  another  kind  of  practice  -  in  situation  S  (conflict),  do  activity  A 
(resolution  procedure)  to  enforce  criteria  C  (whatever  is  most  worth 
preventing/maintaining/achieving  in  this  conflict).  As  such,  the  ARA  simply  provides  that  some 
practices  will  be  supervisory  with  respect  to  others.  This  means  that  they  will  compute  mostly 
over  execution  state  of  other  practices,  and  their  effect  will  be  to  resolve  problems  of  execution 
state. 

We  critically  reviewed  the  Ambiguity  Reduction  Architecture  over  the  course  of  this  project, 
and  in  particular,  our  preliminary  specification  for  its  design.  Our  primary  conclusions  are  as 
follows: 

•  In  our  initial  design,  we  distinguished  between  supervisory  practices  and  base-level 
practices.  However,  we  did  not  provide  a  simple  discipline  for  writing  out  information 
to  which  the  supervisory  practices  may  respond.  We  also  do  not  have  a  general 
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mechanism  for  practices  to  influence  the  execution  of  other  practices,  save  by  direct 
communication.  These  two  factors  were  addressed  by  creating  a  general  memory  store 
that  enables  practices  to  write  out  information,  such  that  others  may  detect  relevant 
patterns  and  initiate  or  advise  execution.  This  general  memory  store  functions  as  a 
shared  resource.  This  is  why  we  earlier  referred  to  “information  within  the  scope  of  the 
information  environment”  rather  than  “information  within  the  information 
environment.”  Monitors  can  monitor  local  information,  as  well  as  space  within  the 
general  memory  store  to  which  they  have  been  granted  access/visibility. 

•  Actors  need  an  associated  state,  which  can  be  modified  under  the  execution  of  actor 
practices  (self,  others)  and  physical  processes.  In  other  words,  actors  have  a  history  and 
a  physical  state  that  may  be  available  to  themselves  and  others.  It  is  feasible  but  very 
inconvenient  to  attach  this  state  to  individual  practices,  rather  than  to  the  actor  as  a 
whole. 

•  Our  original  architecture  focused  strictly  on  practice  encapsulation,  and  so  provided  for 
sensors,  deliberative  practices,  supervisory  practices,  and  effectors.  In  our  studies  using 
the  architecture,  we  discovered  that  we  have  inadequate  provision  for  modeling  sensors 
versus  sensory  practices,  and  effectors,  versus  effecting  practices.  It  is  also  useful  to 
formalize  the  cognitive  resources  available  to  the  actor  -  e.g.,  a  model  of  the  number  of 
‘chunks’  an  individual  can  manipulate  concurrently.  Therefore,  we  decided  to  segregate 
practices  as  one  of  {sensor-driver,  effector-driver,  deliberative,  supervisory}  and  make 
the  resources  on  which  each  depends  explicit. 

•  Resources  are  one  of  {physical  artifacts,  infonnation  objects}.  Resources  are 
implemented  as  a  type  of  actor,  embodying  less  or  more  intentionality  -  less  for  chairs 
and  Word  documents  and  copy  machines,  and  more  for  actors  functioning  in  the  role  of 
resources.  The  chief  difference  between  a  purely  physical  object  and  a  human,  using 
this  approach,  is  that  the  human  actor  has  the  possibility,  through  reflection  and 
learning,  of  changing  criteria.  For  non-intentional  actors,  criteria  are  fixed  unless  and 
until  a  human  changes  them.  At  the  extreme  (chairs,  rocks)  objects  are  actors/practices 
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in  the  degenerate  sense  that  they  have  state,  may  be  acted  upon,  and  operate  according 
to  physical  laws  -  but  beyond  this,  do  not  generate  behavior  ‘on  their  own.’ 

We  remark  that  the  segregation  of  practices  from  the  resources  they  depend  on  clarities  the  use 
of  the  architecture  to  specify  social  actors.  For  example,  it  was  clumsy  before  to  refer  to  an 
individual  as  a  sensor  for  an  organization  (e.g.,  a  reconnaissance  officer  for  a  battalion,  or  a  sales 
division  of  a  firm).  Now,  we:  create  the  organizational  actor,  install  the  relevant  practices  of  the 
individual  in  the  sensor-driver  class  of  practices  for  the  organizational  actor,  create  the  inter¬ 
dependencies  between  that  individual  and  other  individuals  in  the  organization  by  modeling  the 
other  practices  and  their  inter-dependence,  and,  install  any  actual  physical  sensor  artifacts  used 
by  the  individual  in  the  associated  sensor  resource  category.  In  this  way  the  dependencies  among 
actors  are  captured  ‘on  the  effector  side’  of  the  practices  of  the  individual  acting  as  sensor,  and 
the  management  of  resources  are  captured  ‘on  the  sensor  side’  of  the  practices  of  that  individual. 
Of  course,  this  all  depends  ultimately  on  the  fact  that  practices  or  systems  of  practices  may  be 
constituents  of  other  practices. 

In  our  latest  fonnulation,  we  segregated  control  (supervisory,  ambiguity  reduction)  practices 
according  to  the  primary  categories  (sensor,  base,  effector),  and  provided  for  a  highest-level 
control  regime.  Thus  we  have  the  Reactive  Component,  the  Knowledge  Component,  the 
Execution  Component,  and  the  Deliberative  Component.  The  Reactive  Component  contains  the 
Sensor  Practices  of  an  actor,  the  resources  need  by  those  practices  and  the  Control  Practices  that 
resolve  ambiguities  amongst  the  Sensor  Practices.  The  Knowledge  Component  contains  the 
Base  Practices  of  an  actor,  the  resources  need  by  those  practices  and  the  Control  Practices  that 
resolve  ambiguities  amongst  the  Base  Practices.  The  Execution  Component  contains  the 
Effector  Practices  of  an  actor,  the  resources  need  by  those  practices  and  the  Control  Practices 
that  resolve  ambiguities  amongst  the  Effector  Practices.  The  Deliberative  Component  describes 
the  processes  in  which  the  actor  partakes  to  develop  Control  Practices  for  resolving  ambiguities. 
The  image  below  shows  the  interface  for  this  new  Actor  Architecture. 
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2.  Practice  Mapping  Training  Program 

Human-systems  modeling  and  simulation  depends  on  the  ability  of  a  collection  of  analysts  to 
gather  and  formalize  data  on  human-systems  behavior,  based  on  Generative  Practice  Theory. 
Even  analysts  that  wish  to  simulate  human  systems  using  practice  schemata  need  to  understand 
the  theory  and  methods,  though  not  as  deeply  as  those  who  will  gather  behavior  data  and 
formalize  it  as  actors  (practice  schemata  within  the  ARA).  We  describe  our  activities  here. 

We  developed  an  initial  but  detailed  training  program  for  prospective  mappers.  This  program 
included  lectures,  as  well  as  a  carefully  designed  set  of  exercises.  We  begin  with  a  method  we 
developed  to  help  trainees  better  characterize  their  observations  of  human  activity.  Then  we 
present  the  curriculum  for  the  exercises,  followed  by  an  example  training  interaction. 

2.1  Developing  Effective  Observation  Skills 

We  developed  a  new  technique  to  support  initial  training  in  behavior  observation  and  critical 
assessment  of  the  observations.  The  goals  are  to  help  mapper  trainees  begin  to  observe  behavior 
with  as  little  bias  as  possible,  to  give  them  experience  distinguishing  between  what  is  inter- 
subjectively  visible  and  what  is  thought,  and  to  lead  them  into  the  development  of  a  productively 
critical  stance  with  respect  to  the  witnessed  behavior. 

We  illustrate  its 
general  form  here.  In 
essence,  users  have  three 
panels  for  entering 
material  on  behavior 
observations:  a  base 
narrative  to  the  left 
contains  all  externally- 
visible  observations  of 
the  situations,  actions,  and  communication  of  some  human  system  engaged  in  some  activity;  a 
central  panel  in  which  the  user  describes  everything  that  she/he  thought  as  the  observed  activity 
transpired;  and  then  to  the  right  a  critical  reconstruction  of  the  premises  and  larger  potential 


External  Phenomenon  Internal  Phenomenon  Critical  Retrospective 


Observed 
participants, 
conditions,  physical 
performances,  and 
speech  acts,  for 
some  set  of  actors 
engaged  in  some 
activity 


Everything  thought 
but  not  said  about 
the  observations  at 
the  time  of  their 
occurrence 


Critical 

reconstruction  of 
possibilities  for 
action:  information, 
inferences, 
arguments,  choices, 
social  arrangements 

May  be  formalized 
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implied  by  the  observed  activity  (often  fonnalized  as  a  choice  that  encompasses  what  actually 
transpired),  as  well  as  any  views  on  how  observation  or  thoughts  about  the  activity  might  have 
influenced  the  activity. 

We  developed  a  tool  within  ACCORD  that  supports  these  actions,  called  the  “Journal  Tool.” 
(We  refer  to  this  tool  as  the  “Diary  Tool”  -  its  original  name  -  in  the  training  course  curriculum 
that  appears  below.) 

2.2  Practice  Mapping  Training  -  Course  of  Study 

We  developed  a  delivered  a  training  course  on  Generative  Practice  Theory,  Practice  Mapping, 
and  ACCORD,  as  part  of  this  project.  We  describe  this  work  below.  First,  we  offer  a  few  general 
remarks  on  what  we  are  learning  about  training. 

Synergia  is  receiving  increasing  numbers  of  requests  for  training  in  our  theory,  methods,  and 
technology,  and  has  now  trained  a  substantial  number  of  candidates,  with  widely  varying 
backgrounds  and  application  interests.  A  number  of  candidate  trainees  have  been  presented,  and 
we  are  evaluating  our  experience,  as  a  precondition  to  improving  training. 

We  require  computer  science  background  for  any  trainee  that  will  be  developing  simulation 
models.  Beyond  this,  we  have  not  issued  specific  requirements;  training  is  meant  to  be 
comprehensive.  In  many  but  not  all  cases,  we  have  had  the  opportunity  to  participate  in  the 
selection  of  the  candidate  for  training. 

We  find  that  trainees  vary  in  terms  of  native  aptitude  -  by  which  we  mean  their  sensitivity  to 
cognitive  and  social  phenomena,  and  in  their  ability  to  abstract  and  formalize  observations  of 
such  phenomena.  However,  aptitude  has  not  proven  to  be  a  barrier  to  success.  For  example, 
event-behavior  graphs  appear  to  be  readily  understood  and  with  training  and  a  little  practice 
easily  fonned,  regardless  of  aptitude. 

We  also  find  that  trainee  candidates  vary  in  their  desire  to  learn  our  theory,  methods,  and  tools, 
with  very  distinct  impact  on  the  effectiveness  of  training.  The  first  type  of  trainee  expresses 
disinterest  in  undergoing  training,  prima  facie  disbelief  on  new  approaches  like  ours,  or  even 
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distaste  for  the  effort  required.  The  second  type  of  candidate  expresses  optimism  or,  at  least, 
curiosity  regarding  our  methods  and  their  usefulness.  The  first  type  of  candidate4  struggles  and 
requires  far  more  time  and  effort  from  the  instructor  than  does  the  latter.  The  latter  type  of 
trainees  has  consistently  produced  useful  models  and  analyses  right  away,  and,  on  their  own 
initiative,  many  of  these  have  taken  steps  to  promote  the  approach  within  and  even  outside  of 
their  organization. 

After  having  trained  a  significant  number  of  candidates  -  many  more  than  on  this  contract  - 
we  find  that  well  over  two-thirds  are  in  the  latter/productive  category.  We  find  we  only 
experience  the  first/difficult  trainee  when  we  do  not  get  to  participate  in  the  selection  of  the 
candidate.  Therefore,  we  conclude  that  a  careful  screening  process  is  essential  for  training 
candidates  to  ensure  that  they  are  properly  motivated  and  provided  sufficient  incentives  to  ensure 
an  appropriate  level  and  quality  of  effort. 

We  continue  now  with  specimens  of  training  on  this  contract. 

2.2.1  Prefatory  Remarks 

There  are  three  components  of  Practice  Mapping  training.  You  will  be  working  on  them  in 
parallel.  In  order  of  increasing  importance,  and  with  my  suggestions  for  the  relative  amount  of 
time  and  effort  you  devote  to  each: 

•  20%  background  studies  on  decision  analysis, 

•  30%  learning  the  ACCORD  tools,  and 

•  50%  beginning  to  map  a  JF ACC. 

In  the  case  of  all  of  this  work,  call  or  send  me  questions  at  any  time.  If  I'm  busy  at  the  moment 
of  a  call,  we’ll  arrange  a  time  to  discuss  or  decide  what  to  send  me. 

Of  course,  send  or  call  with  questions  on  this  program. 

Never  set  something  aside  because  it  doesn’t  make  sense  or  because,  in  trying  it,  something 
didn’t  work  out.  Get  my  help.  This  is  the  only  way  I  can  learn  what  you  need!!!  More 


We  have  had  candidates  that  opted  out  of  training.  Our  remarks  here  apply  to  those  who  have  taken  the  training. 
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importantly,  you  should  know  that  a  significant  aspect  of  learning  our  work  is  learning  to 
function  as  an  apprentice.  We  train  the  most  critical  things  by  starting  with  whatever  poses  a 
problem. 

Send  me  specimen  products  at  the  end  of  each  week  or  two  (don’t  go  longer  than  2  weeks!!), 
so  that  I  can  see  how  it’s  going.  Send  me  things  right  away  when  you  start  a  new  activity  -  e.g., 
the  first  time  you  analyze  a  newswire  story,  send  me  your  result  so  I  can  check  in  and  help  if 
needed. 

2.2.2  Background  Decision  Analysis  Studies 


1 .  Begin  learning  decision  analysis. 

a.  Study  chapters  1-4  Making  Hard  Decisions,  (Clemen)  2nd  edition. 

b.  For  chapters  1-4  you  should  read  every  problem  and  assure  yourself  you  have  a 
good  feeling  for  what  it  is  asking  you  to  do.  If  you  wish,  work  some  portion  of  the 
problems. 

c.  Don't  worry  about  using  the  DecisionTools  software;  if  you  find  yourself  wanting 
to  use  tools,  use  ours  instead.  This  will  help  us  think  about  what  we  need  to  add 
or  revise. 

2.  Optional:  if  you  want  to  leam  more  about  value,  and  value  modeling,  read  chapters  1-5  of 
Value  Focused  Thinking  (Keeney) 


2.2.3  ACCORD  Explorations 

1 .  Use  the  diary  tool  once/day  or  at  least  a  few  times  per  week. 

a.  Fill  in  the  narrative  and  private-thoughts  sections.  We'll  get  to  the  third  column 
(critical  reflections  on  foregoing)  in  a  while. 

b.  Pick  activities  —  preferably  multi-person  ones  —  in  which  participants  were 

i.  analyzing  or  figuring  something  out, 

ii.  deciding  something, 

iii.  a  conclusion  was  shared  that  is  pertinent  to  some  choice  of  one  of  the 
participants,  or 
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iv.  a  choice  of  one  participant  was  transmitted  to  another  (e.g.,  boss  gives 
direction  on  what  to  do). 

2.  Analyze  each  of  the  newswire  files  you  will  find  in  appendix  that  follows.  Begin  by 
doing  a  “GPT  markup”  of  each  separate  article. 

a.  You  can  do  this  by  creating  a  table  for  each  article,  if  you  wish  -  elements  of  the 
GPT  vocabulary,  and  instances  in  the  article.  Or,  you  might  put  the  article  in 
PowerPoint  and  then  color  patches  of  text  with  a  distinctive  color  for  each  kind  of 
item  (e.g.,  actors  are  orange,  roles  are  blue,  objects  are  green,  etc.) 

b.  Specifically,  identify: 

i.  actors  (individuals,  groups) 

ii.  behavior  and  behavior  trajectories:  this  happened,  this  was  done,  then 
this  happened,  and  this  was  then  done,  etc. 

iii.  events:  key  occurrences,  e.g.,  that  happened  right  before,  during,  or  after  a 
behavior  and  that  seem  to  trigger  behavior,  affect  it,  or  be  its  result 

iv.  objects:  stuff  that  is  important  to  the  story) 

v.  physical  processes  (if  important.,  e.g.,  weather).  Note  human-processes 
appear  as  behavior  and  behavior  trajectories. 

vi.  resource  dependence:  anything  you  find  that  tells  who  uses,  produces, 
consumes,  transfers,  owns,  or  has  some  other  relationship  with  an  object 

vii.  communication:  originator,  topic,  and  intended  audience 

viii.  roles:  a  role  is  a  collection  of  behaviors  or  tasks  that  various  actors  may 
play  in  a  similar  way  (e.g.,  doctor,  lawyer,  president,  policeman).  Titles, 
and  anything  that  signifies  authority  goes  here.  Often  you  will  see  roles  in 
role  relations,  e.g.,  doctor/patient. 

3.  Once  you  have  completed  the  markup  task,  build  EBGs  in  ACCORD  for  each  news  story 

4.  Describe  a  real  choice  problem  —  an  important  decision  you  know  about  (perhaps 
because  its  yours!) 


2.2.4  Client-Centered  Mapping 


1 .  Begin  gathering  data  on  a  JFACC. 

a.  To  the  extent  that  you  can,  start  by  gathering  infonnation  on  primary  functions 
accomplished  by  the  primary  actors  of  the  organization.  I.e.,  try  to  look  at  what 
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various  groups  and  a  (perhaps)  few  key  individuals  accomplish  first,  rather  than 
trying  to  understand  any  particular  job  station  in  depth. 

b.  We  will  proceed  by  refining  the  description  after  we  have  the  overall  view 
developed. 

2.  Do  not  start  with  interviews.  Begin  by  gathering  existing  materials  on  the  design  and 
operation  of  the  JFACC. 

a.  Also  look  for  material  that  expresses  criticism  or  thoughts  on  how  it  could  be 
better. 

b.  If  you  happen  to  attend  interviews,  capture  the  results  in  terms  of  the  maps  that 
follow. 

3.  Analyze  the  materials  you  gather  to  build  up  the  following  maps.  Let  me  know  any  time 
you  find  you  have  info  you  think  important  and  you  don’t  know  how  to  enter  it  into  one 
of  these  maps. 

a.  Actor  //  Task  Map.  Your  product  is  a  map  of  individuals  or  groups,  and  for  each, 
their  typical  tasks/jobs.  The  following  are  kinds  of  things  we  would  like  to  know 
about  every  task/actor  relationship.  You  won’t  know  this  about  every  task,  but 
ideally,  we’ll  get  this,  or  most  of  it,  for  key  tasks. 

i.  Develop  a  list  of  all  key  tasks  accomplished  in  a  JFACC.  How  do  we 
recognize  a  task? 

1.  A  task  is  basically  a  statement  of  an  objective:  create  this  product, 
form  this  prediction,  make  this  decision,  achieve  this  condition, 
certify  this  conclusion,  etc. 

2.  Sometimes  you  will  leam  of  tasks  directly  -  here's  a  task,  and 
these  folks  over  here  accomplish  it. 

3.  Other  times,  you'll  identify  the  individual  or  group  actor,  and  then 
seek  to  know  the  jobs/tasks  they  are  responsible  for. 

4.  Still  other  times,  you  will  identify  a  database  or  kind  of  result  (e.g., 
plan  or  plan  update)  whose  contents  are  the  result  of  tasks  to  fill  or 
update  it,  and  whose  users  evidently  have  still  others  tasks  that 
require  use  of  the  contents  of  the  database.  So  you’ll  infer  from 
data  types  or  other  knowledge  structure  to  producers  (and  their 
tasks)  and  consumers  (and  their  tasks). 

ii.  What  person  *or  group*  does  them? 

iii.  Who  assigns  the  task,  or  how  is  it  discovered/articulated? 

iv.  For  tasks  accomplished  by  groups,  is  there  authority  over  the  process  of 
doing  the  task? 
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1.  e.g.,  is  someone  in  charge  of  accomplishing  it? 

2.  e.g.,  who  certifies  that  the  task  has  been  accomplished,  or  should 
be  suspended  or  aborted? 

v.  What  is  the  essential  training  the  person  or  group  has  to  do  the  work? 

vi.  What  counts  as  success  or  great  quality  for  the  task?  Take  care  to 
distinguish  deadline  requirements  from  other  measures  of  quality. 

vii.  What  counts  as  failure  or  low  quality?  Again,  distinguish  deadlines  from 
other  measures  of  quality. . . 

viii.  Task  data  will  not  all  arrive  in  the  same  format;  you’ll  need  to  be  flexible 
about  this. 

b.  Task  //  Info&Choice  Content  Map.  Your  product  is  the  specification  of  key 
information,  choices,  and  critiques  associated  with  specifying  or  accomplishing 
tasks.  For  each  task/job,  identify: 

i.  key  analyses  perfonned  (i.e.,  infonnation  products  created),  be  especially 
alert  for  any  mention  of  CREATION  of  forecasts  or  predictions 

ii.  key  information  used 

iii.  source  of  key  infonnation:  creation,  communication  with  others,  database 
access,  model  or  simulation  study,  . . . 

iv.  distribution  of  information:  who  it  is  shared  with,  and  how  (e.g., 
conversation,  in  database  that  another  accesses,  etc.) 

v.  decisions  that  are  formed  and  taken,  or  revised/updated,  as  part  of  a  task 

vi.  dependence  of  decisions  on  information  products  (e.g.,  who  consumes 
information  produced  by  the  task,  and  for  what  choices?)  be  especially 
alert  for  any  mention  of  USE  of  forecasts  or  predictions 

4.  On  interviewing  staff  to  gather  information: 

a.  Do  not  seek  to  interview  anyone  until  we  have  done  all  we  can  without  that,  or  at 
least,  until  we  discuss  the  benefits  and  costs  of  doing  this. 

b.  If  you  participate  in  interviews  then  capture  the  information  in  the  prior  fonnat. 
Ideally,  tape  the  interviews  and  come  back  and  analyze  it  into  these  two  maps. 

c.  For  each  task/job,  include  annotations  for  any  critical  remarks  —  ways  things 
could  or  should  be  done  better,  problems  or  difficulties,  puzzles,  etc.  absolutely 
capture  this  information  —  critique  is  often  of  vital  importance 

d.  For  what  its  worth,  it  is  my  hope  that  you  and  the  persons  you  interview  will  find 
this  a  useful  fonnat  for  these  interviews.  If  so,  I  can  help  a  bit  to  refine  it  so  that 
you  can  lead  others  to  tell  you  information  in  this  form. 


28 


2.3  Sample  Training  Interaction 

In  Practice  Mapping  training,  the  goal  is  to  lead  the  trainee  to  see  human  systems  in  terms  of 
Generative  Practice  Theory  -  to  see  behavior  and  joint  behavior  as  the  product  of  criteria- 
seeking  (adaptive)  generators.  And,  we  aim  to  teach  a  form  of  best-practices  for  the  design  of  the 
ontology  that  guides  observation,  event,  and  behavior  capture. 

The  following  is  an  (un-edited)  example  of  a  sample  problem,  mapping  a  newswire  report,  the 
work  of  the  trainee,  and  the  commentary  provided  on  the  trainee’s  work.  We  wish  to  draw 
attention  to  the  way  we  treat  the  work  of  the  trainee  as  an  entry  point  into  the  necessary  theory 
and  a  better  methodology  -  mappers  are  developed  through  practice.  In  this  way  trainees  have 
concrete  data  on  which  to  base  their  learning. 

Here,  we  show  the  first  step  in  the  process  of  becoming  a  mapper  -  learning  to  properly 
recognize  and  classify  the  elements  of  some  sample  data,  shown  here. 

Source:  Radio  Afghanistan 

30  December  2004 

Police  seize  1,485  kg  of  raw  hashish  in  southeastern  Afghan  province 

Police  seized  1,485  kg  of  raw  hashish  in  [southeastern]  Paktia  Province  yesterday. 

According  to  another  report,  farmers  have  voluntarily  cleared  20  hectares  of  land  of 

opium  poppies  in  11  villages  in  Chamkani  District  in  Paktia. 


[Correspondent  in  Pashto]  In  line  with  the  fight  against  the  cultivation,  production  and 
trafficking  of  drugs,  officers  of  the  Criminal  Department  of  Paktia  Province  seized  1,050 
kg  of  raw  hashish  in  Levan  Village  in  the  Machalghu  area  and  officers  of  the 
Antiterrorism  Department  discovered  435  kg  of  raw  hashish  in  Sayd  Karam  District 
yesterday.  Minister  Adviser  and  Paktia  Governor  Asadollah  Wafa,  Security  Commander 
Maj-Gen  Soleman  Khel  and  the  heads  of  government  offices  were  present  when  the 
hashish  was  transferred  to  the  Security  Command.  Mr  Wafa  thanked  the  vigilant  officers 
of  the  Security  Command  for  their  fight  against  drugs. 
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According  to  another  report,  farmers  have  voluntarily  cleared  20  hectares  of  land  of 
opium  poppies  in  the  villages  of  Star,  Babu  Khel,  Alem,  Mirjani,  Hesarak  and  Kodgi 
Hesarak.  Mohammad  Darwesh,  Paktia  Province,  for  Radio  Afghanistan. 


The  trainee’s  map  follows,  with  our  instructional  remarks  interspersed. 
Observation 


•  Observation  Type: 

o  Anti-Drug  Operation 

■  Start  Date/Time: 

•  12/29/04,  Datum  Date  12/30/04 

■  End  Date/Time: 

•  12/29/04,  Datum  Date  12/30/04 

■  Location: 

•  Paktia  Province  [southeastern  Afghanistan] 

■  Source: 

•  Mohammad  Darwesh 

■  Source  context  or  role: 

•  Radio  Correspondent 

■  Transmitting  Source: 

•  Radio  Afghanistan 

■  Contents: 

•  The  full  data  is  referenced  here 


The  time  of  the  observation  is  12/30/04.  We  distinguish  between  the  time  of  the 
observation,  which  often  reports  on  earlier  events  or  behaviors,  and  the  time  of  the  events 
and  behaviors. 


30 


This  is  an  example  of  the  way  observations  are  evidence  for  inferred  events  and 
behaviors... 

Note  that  events  and  behaviors  therefore  each  have  underlying  observations  -  in  this 
case,  each  event  and  behavior  has  as  evidence  an  extract  from  the  source.  In  turn,  the 
extract  points  to  the  overall  document. 

Since  you’d  have  many  observations  if  you  did  things  this  way  it’s  probably  better  to 
start  using  ACCORD... 

Observation  context  generally  means  the  conditions  that  led  to  the  observation  being 
made.  We  don’t  really  care  here. 


Actors 


•  Drug  Smugglers 

•  Officers  (  Criminal  Department  of  Paktia  Province,  Antiterrorism  Department ) 

•  Officials  (  Governor,  Security  Command  Members,  and  Government  Offices  ) 

•  Fanners 

Lumping  actors  into  super-actors,  as  you’ve  done,  is  useful  in  some  cases  but  not  all.  It 
depends  on  whether  we’ll  have  an  interest  in  the  constituents  as  we  continue  to  model. 
Here,  we’ll  want  to  break  them  out  (see  notes  on  Behavior,  below). 

Security  Command  is  an  important  actor.  We  may  suspect  that  this  actor  has  as 
constituent  actors  the  Criminal  Dept,  and  the  Antiterrorism  Dept.  In  a  typical  mapping 
engagement,  we  would  confirm  or  disconfirm  this,  by  establishing  the  relationship  among 
the  three  actors. 
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Events 


•  Event  Type:  Drug  Seizure 
o  Location: 

■  Paktia  Province:  Levan  Village(Machalghu  area),  Sayd  Karam  District 
o  Drugs  and  amounts  seized: 

■  Hashish:  1,050kg  Levan  Village;  435kg  Sayd  Karam  District 

If  we  were  doing  this  in  the  tools,  you’d  distinguish  the  drugs  property/feature  of  the 
event  type  “drug  seizure”  from  the  amounts. 

I  have  a  preference  for  more  general  event  types,  i.e.,  “seizure”  over  “drugs  seizure.”  The 
generality  of  the  type  is  always  important  to  consider  -  i.e.,  you  are  making  an  important 
choice  here.  In  this  domain,  arms  are  seized  too.  So  to  create  the  “drug  seizure”  type  is  to 
map  it  as  if  this  is  the  only  seizure  we  care  about,  or  to  commit  to  separate  types  for 
separate  kinds  of  items  seized  -  e.g.,  “drug  seizure”,  “small-arms  seizure”,  “wmd  seizure”. 
The  important  thing  is  to  think  about  the  practice  of  the  actor.  If  seizing  one  thing  versus 
another  is  essentially  the  same  behavior,  then  the  event  likely  abstracts  over  the  various 
things  seized. 


•  Event  Type:  Land  Clearing 
o  Location: 

■  Paktia  Province:  Chamkani  District(l  1  villages) 
o  Drug  type  and  land  size: 

■  Opium  poppies:  20  hectares  of  land 

You  evidently  chose  this  type  from  the  text  of  the  observation.  But  if  you  read  the  text 
again,  you  can  see  that  it’s  not  about  land,  but  rather,  poppy  eradication...  “clear  the  land 
of  opium  poppies”...  That  is  what  the  text  is  really  conveying,  and  it  is  an  event  pertinent 
to  the  practice  of  interest.  So  the  event  type  “eradication”  would  be  more  suitable. 
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Again,  drug  type  and  land  size  are  separate  features  of  the  type. 


Behaviors 

•  Behavior  Type:  Anti-drug  Operation 

o  Location: 

■  Paktia  Province:  Levan  Village(Machalghu  area),  Sayd  Karam  District 
o  Actor: 

■  Officers 
o  Location: 

■  Paktia  Province:  Chamkani  District(l  1  villages) 
o  Actor: 

■  Fanners 

Earlier,  the  event  type  was  (perhaps)  too  specific.  Here,  the  behavior  type  is  (perhaps)  too 
general.  There  are  lots  of  anti-drug  operations.  We  see  this  because  there  are  four 
behaviors,  not  one: 

•  seizure  (implying  a  planned  raid), 

•  discovery  (implying  they  were  doing  something  else  not  mentioned) 

•  transfer  to  the  Security  Command 

•  eradication  efforts 

Each  should  be  separately  mapped,  because  they  are  distinct  occurrences,  and  because 
they  are  accomplished  by  distinct  actors  (and  so  evidence  for  separate  practices!!!!). 
Always  keep  in  mind  we  seek  to  understand  practices  -  event  and  behavior  mapping  is  in 
service  to  this  primary  aim. 

We’d  like  other  info  to  decide  best  how  to  map  the  accidental  discovery.  We  can  safely 
assume  the  officers  are  always  looking  for  drugs,  whatever  they  are  doing.  Knowing  only 
what  we  know,  I’d  say  we  should  focus  on  a  single  behavior  type,  “SeizeContraband”,  for 
the  seizure  and  the  discovery,  since  the  latter  does  involve  seizure...  Later,  if  we  learn  of 
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other  practices  that  may  (as  a  side-effect)  uncover  drugs,  we  can  model  this.  I  would 
strongly  oppose  a  “discover”  behavior. 

Note  the  discovering  actors  are  in  the  Antiterrorism  Dept.  In  some  mapping 
engagements,  we  would  treat  this  as  a  clue  to  their  practice.  Here,  I  think  the  key  inference 
to  draw  is  that  fighting  terror  and  fighting  drugs  are  correlated.  Otherwise,  the  anti-terror 
guys  would  just  hand  off  the  drugs  to  the  criminal  dept  and  go  back  to  their  stuff,  whereas 
here,  they  both  are  named,  both  get  credit,  etc. 

Objects 

•  Hashish 

•  Opium  poppies  [land] 


Land  is  separate 


Resources 

•  No  data 

Depends  on  what  we  want  to  model.  The  land,  for  example,  is  a  resource  for  farmers. 
And  later,  the  poppy  plants  function  as  a  resource  for  the  exchange  practices  that  sell  them 
for  money... 

Communications 

•  No  data 


Again,  depends  on  our  modeling  interests.  The  statement  by  Mr.  Wafa  may  be  worthy  of 
note  -  e.g.,  if  we  are  modeling  the  emergence  of  anti-drug  rhetoric  in  the  nation. 
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In  general,  the  comments  of  participants  on  activities  are  VERY  instructive. 
Here,  you  should  map  it  just  to  think  through  the  communication  activity. 


Roles 

•  Drug  Smuggler 

o  Cultivate  and  Manufacture  Drugs 
o  Procure,  hide,  and  smuggle  drugs  out  of  country 

•  Drug  Control 

o  Investigate  and  probe  for  drug  smuggling  activity 
o  Seize  drugs 

•  Fanners 

o  Voluntarily  assist  in  the  reduction  of  drug  production 

We  do  not  actually  know  much  about  the  contents  of  these  roles  from  this  one  document, 
especially  for  the  smugglers  and  officers. 

Roles  are  three  things: 

1.  a  set  of  tasks  that  the  role-playing  actor  nominally  undertakes;  or,  dually, 
expectations  for  kinds  of  events  (usually,  over  time)  that  will  be  produced 

2.  a  collection  of  choices  that  are  customarily  part  of  accomplishing  the  tasks 

3.  resources  customarily  or  necessarily  available  to  accomplish  the  tasks 


We  don’t  have  a  lot  of  info  in  this  document,  but,  you  should  go  back  through  and  think 
about  the  roles  along  these  three  dimensions.  You  should  do  this  with  all  other  role- 
analyses  going  forward. 

One  reason  role  analysis  is  important  is  that  we  have  few  of  the  actual  participant  actors 
-  we  are  learning  about  kinds  of  behaviors/practices  rather  than  about  the  behavior  of 
specific  individuals.  Equivalently,  we  have  actor  types  but  not  actor  instances  for  the 
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farmers  and  officers.  So  the  actual  actors  are  things  like  Farmersinstance#,  CDPP- 
Officersinstance#,  etc.  It  is  typical  for  this  work  that  we  learn  about  kinds  of  behavior 
without  knowing  more  than  the  kind  of  actor  -  and  so  we  focus  on  roles. 

You  might  think  about  this  distinction  from  the  point  of  view  of  simulation.  Here,  we’d 
spawn  actor  instances  as  needed. 

Clearing  land  of  poppies  is  much  less  than  assisting  in  reduction  of  drug  production. 
They  can  replant  next  week...  We  have  to  stick  with  what  they  actually  did,  in  the  concrete 
circumstances  that  obtained. 


Critique 

•  There  is  this  ‘According  to  another  report’  reference  which  I  don’t  know  how  to  markup. 
It  almost  seems  like  an  actor  but  not  modeled  such  as  the  correspondent.  I  wouldn’t  call 
it  a  resource  because  it  didn’t  affect  behavior.  I  wouldn’t  call  it  an  object  because  it’s  not 
an  item  in  an  event.  I  decided  on  not  mapping  it  because  it  seems  like  nothing  more  than 
a  conduit  for  infonnation  such  as  the  correspondent. 

o  Fine.  If  we  capture  the  observations  properly  we  get  this  for  free. 

•  The  final  paragraph  repeated  the  Land  Clearing  so  it  didn’t  need  to  be  mapped  again  but 
it  did  contain  a  little  more  information;  several  village  names. 

o  The  inferred  events  and  behaviors  have  as  evidence  information  from 
various  patches  of  text  (collected  as  one  observation). 

•  For  the  Land  Clearing  behavior,  I  wasn’t  sure  if  it  was  right  to  lump  all  the  villages  under 
Paktia  Province  and/or  Chamkani  District  or  to  list  as  many  villages  as  possible  or  just 
the  number  involved.  I  went  with  Paktia  Province:  Chamkani  District(  1 1  villages).  I 
figure  the  specific  village  names  can  be  looked  up  later  on  if  they  are  needed. 

o  As  I  said  above,  these  are  to  be  separately  mapped.  They  come  together  via 
the  transfer  behavior. 

•  There  was  no  communication  to  markup,  except  between  Wafa  and  Security  Command 
which  isn’t  of  special  interest. 

o  As  per  previous  comments,  we  do  not  know  this.  It  could  be  the  most 
important  thing  to  map. 

•  I  found  no  data  on  resources  that  effect  behavior. 

o  I’d  err  on  the  side  of  trying  to  assign  every  object  as  a  resource  for  some 
practice. 
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o  If  you  -  as  analyst  -  are  not  going  to  practices  yet  (e.g.,  you  are  just  doing  the 
EBGs)  then  a  solution  to  keep  things  around  is  to  create  a  feature  of  a 
behavior  type  such  as  “associated  resources” 

•  For  the  physical  date  I  used  the  day  before  the  date  listed  on  the  datum  because  the 
events  took  place  ‘yesterday’  according  to  the  report.  Since  we  are  capturing  the 
observation  itself  I  also  put  down  the  date  on  the  datum. 

o  Events  and  behaviors  are  ‘yesterday’,  observation  is  ‘today’. 

•  I  joined  the  Criminal  Department  of  Paktia  Province  and  the  Antiterrorism  Department 
together  as  one  actor  called  Officers  because  they  filled  the  same  role  and  perfonned  a 
similar  event.  I  did  decide  to  make  note  of  this  join  in  the  Actors  section.  Same  goes  for 
the  Officials  group. 

o  This  decision  needs  to  be  made  in  terms  of  the  actors  or  practices  we  seek  to 
understand  -  i.e.,  not  because  they  have  a  prima-facie  similarity  of  roles. 

o  When  in  doubt,  don’t  combine. 

•  I  made  note  of  the  Officials  for  future  reference  but  there  wasn’t  any  reason  to  map  them 
here. 

o  Since  the  transfer  and  communications  are  important,  you  need  them. 
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Appendix  A:  Generative  Practice  Theory 


Generative  Practice  Theory  -  Modeling  Behavior,  Skill,  Individuals, 
Organizations,  and  Culture 

We  describe  our  theory  of  human  systems,  Generative  Practice  Theory.  This  theory  contributes 
a  generative  mechanism  sufficient  to  model  primitive  and  complex  skills,  individuals  and  their 
personalities,  and  any  desired  social  fonnation,  such  as  teams,  organizations,  and  institutions. 
We  begin  with  the  conceptual  foundations,  than  present  our  theory  of  personality,  ideology,  and 
culture  as  extensions  to  the  base  theory. 

Conceptual  Framework 

Situations  never  exactly  repeat.  And,  there  is  no  behavior  that  is  an  exact  image  of  another  prior 
behavior.  Instead,  human  individual  and  social  competence  creates  similar,  valued  outcome 
situations,  for  the  widest  possible  range  of  input  situations.  This  ability  to  adapt  to  a  variety  of 
situations,  and  to  regularly  produce  more-favored  situations,  reveals  the  presence  of  criteria. 
Criteria  name  the  values-in-action,  the  ‘control  laws’  that  govern  or  guide  -  adapt  -  behavior. 
The  presence  of  criteria  establishes  how  behavior  can  be  provided  for  and  managed  within 
situations  the  actor  has  not  yet  met.  Intelligent,  resource-constrained  actors  must  have  this 
capability  -  lacking  omnipotence,  we  must  be  capable  of  adapting  to  new  situations.  Criteria- 
managed  behavior  is  adaptive  behavior. 

Representing  Behavior 

We  distinguish  behavior,  which  is  a  manifestation  of  an  actor’s  skill,  from  practices,  which 
formalize  the  skill  as  a  whole.  Practices  are  hypothesized  generators  sufficient  to  produce  and 
adapt  behavior  as  a  function  of  situational  conditions.  Situations  are  collections  of  events. 
Behavior  is  what  we  observe,  while  practices  depict  the  capacity  of  the  actor  to  produce  and 
adapt  -  that  is,  manage  -  behavior.  From  the  point  of  view  of  analysis,  behaviors  are  evidence 
for  practices,  and  practices  hypothesize  the  generator  that  produces  those  (and  other)  behaviors. 


We  have  developed  and  validated  a  representation  language  to  capture  observations  about 
behavior.  This  language,  Event-Behavior  Graphs  (EBGs),  is  a  directed  graph  fonned  from 
event  and  behavior  nodes,  and  directed  links.  Event  nodes  depict  occurrences  and  relations  over 
occurrences,  and  have  an  associated  temporal  extent  (an  interval).  Events  may  depict  physical, 
cognitive,  and  social  states  of  affairs.  Behaviors  are  activities  that  abstract  over  a  set  of  events, 
have  a  temporal  extent,  and  are  identified  as  being  undertaken  by  some  actor.  The  actor  may  be 
an  individual  or  a  social  actor. 
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A  link  from  an  event  into  an  event  represents  temporal  precedence.  A  link  from  an  event  into  a 
behavior  signifies  that  the  event  is  either  a  (partial)  cause  that  triggers  the  event,  or  an  element  of 
context  (like  the  location)  that  shapes  the  way  the  behavior  transpires.  Links  from  behaviors  into 
events  signify  that  the  events  were  produced  by  the  actor  via  that  behavior.  Links  into  and  out  of 
behavior  are  hypotheses  (of  an  observer)  about  the  intentions  and  performance  capabilities  of  the 
actor  producing  the  behavior  -  as  per  the  previous  remarks  on  criteria-driven  behavior. 


Event-behavior  graphs  are  hierarchical  because  events  can  summarize  entire  event-behavior 
graphs,  and  because  behaviors  can  summarize  over  constituent  behaviors.  In  the  latter  case,  if  the 
upper-level  (abstracted)  behavior  is  conducted  by  an  individual,  then  the  refinement  nodes  depict 
sub-methods  of  the  individual,  and  their  intermediate  products  and  results.  If  the  abstracted 
behavior  is  the  product  of  a  social  actor,  then  the  refinement  graph  depicts  constituent 
contributions  of  actors  that  are  themselves  constituents  of  the  social  actor  that  produces  the 
abstracted  behavior.  Hierarchy  in  EBGs  enables  us  to  model  at  any  desired  level  of  abstraction, 
and  then  to  refine  elements  -  componential  and  social  decomposition  -  as  needed. 


At  the  end  of  this  document  we  include  a  brief  image  of  Synergia  technology  for  developing  and 
managing  event-behavior  graphs. 

Practices  -  Modeling  the  Generators  of  Adaptive  Behavior 

We  now  describe  the  fundamental  construct  for  our  work,  the  practice.  Then  we  show  it  is 
sufficient  to  represent  individual  and  social  actors,  and  to  enable  us  to  formalize  what  we  mean 
by  personality,  ideology,  and  culture. 


The  language  of  practices  enables  users  to  formalize  observations  of  situated  behavior  in  terms 
of  a  summarizing  dynamic  capacity.  A  practice  is  defined  by  a  triple:  a  set  of  situations  S,  an 
action  generator  A,  and  a  set  of  criteria  C.  The  situation  represents  the  information  state 
monitored  and  created  by  the  practice,  as  behavior  is  produced  by  the  action  generator.  Criteria 
evaluate  the  current  situation  and  orient  behavior  to  improve  it,  and  may  take  the  form  of  goals, 
proscriptions,  preferences  and  tradeoffs,  conditions  that  legislate  among  contingencies,  success 
and  failure  conditions,  interrupt  conditions,  etc.  We  can  use  a  propositional  form  to  express  the 
relations  among  its  elements: 


For  all  Situations  of  type  S,  Do  Actions  A  so  as  to  enforce  Criteria  C 


Practices  are  behavior  generators  that  seek  to  satisfy  some  criteria  by  transforming  antecedent 
situations  into  more  satisfactory  consequent  situations.  Actors  regularly  seek  to  create  particular 
kinds  of  consequences,  often  for  a  very  wide  variety  of  starting  conditions.  Just  as  conditions 
vary,  behavior  never  exactly  repeats  in  all  of  its  details.  Of  course,  it  is  impossible  for  actors  to 
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embody  a  separate  rule  or  behavior  for  each  of  the  infinite  number  of  feasible  starting  conditions. 
It  is  impossible  to  learn  all  the  distinct  rules,  and  impossible  to  store  them.  Thus  we  are  led  to  the 
central  innovation  and  importance  of  the  practice  construct.  By  introducing  criteria  as  a 
foundational  component  of  behavior  production,  practices  make  it  possible  for  actors  to  embody 
a  very  compact  ‘machine’  that  adaptively  manages  behavior  production  across  a  range  of  events. 
Criteria  enable  actors  (and  us  as  modelers!)  to  ‘fill  in  the  gaps’  and  so  generate  effective 
behavior  in  new  situations. 


In  general,  A  may  be  adjusted  multiple  times,  even  continuously,  to  (attempt  to)  satisfy  C.  This 
leads  us  to  express  the  above  propositional  form  as  a  dynamic  system,  or  equally,  as  a 
computational  system.  Practices,  as  systems,  are  composed  of  a  set  of  monitors,  a  set  of  action 
generators,  and  a  set  of  data  managers.  For  this  form  we  introduce  execution  resources,  R,  since 
behavior  is  the  product  of  a  physically-embodied  actor  and  so  necessarily  consumes  resources 
during  execution.  We  have: 


Concurrently,  subject  to  resources  R: 

Maintain  a  description  of  the  situation  S  ; 

Monitor  for  departure  from  the  satisfaction  of  criteria  C  in  S  ; 

Supervise  execution  of  action  generator  A  to  maximize  satisfaction  of  C  in  S  ; 


Monitors  are  responsible  for  activating  the  generator  A,  and  for  suspending  it  under  conditions 
of  success,  failure,  resource  limitations,  or  as  directed  by  practices  that  contain  this  one.  A  is 
designed  to  be  advisable  by  the  deviations  measured  by  the  monitors  -  action  generator  inputs 
include  the  primary  information  relevant  to  the  behavior,  as  well  as  an  ‘error  signal’  created  by 
the  monitors.  Monitors  determine  the  ongoing  state  of  resources  -  a  part  of  the  situation  for  the 
practice  -  and  deposit  signals  that  manage  A  with  respect  to  R,  or  undertake  actions  to  acquire 
additional  resources.  Data  managers  maintain  the  situation  S.  They  accept  data  generated 
external  to  the  practice  and  maintain  it  as  well  as  internally-generated  data.  They  may  keep  all  or 
part  of  the  data,  and  may  manipulate  the  data  to  best  serve  monitoring. 


We  develop  models  of  actor  practices  from  the  infonnation  in  event-behavior  graphs.  The  graphs 
record  situations  -  collections  of  starting,  in-process,  and  concluding  events.  They  also  depict 
the  underlying  action  logic  and  so  the  program  that  defines  the  action  generator  -  the  sequential, 
concurrent,  and  conditional  relations  over  behaviors  that  intervene  between  antecedent  events  S' 
and  consequent  events  S+.  The  action  generator  responds  to  the  situation,  to  better  satisfy  the 
criteria.  We  analyze  the  transfonnation  from  S'  to  S+  within  each  EBG,  and  across  EBGs  - 
variations  in  the  situations  and  action  logic  extend  and  refine  our  understanding  of  the  relevant 
situations  and  actional  capacity  of  the  actor  -  and  above  all  else,  the  criteria  rationalize  the 
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transformation.5  For  example,  consider  behavior  variation  (for  some  practice)  that  is  attributable 
to  resource  variation.  Here,  we  may  analyze  the  behavior  for  what  is  preserved  versus  left  aside, 
to  see  how  the  actor  exploits  (or  copes  with)  differing  qualities,  quantities,  or  availability  of  the 
resource.  We  learn  an  adaptation  scheme  that  embodies  (nothing  need  be  articulated!)  a  tradeoff 
that  favors  some  situations/results  over  others,  as  a  function  of  resources.  Thus  a  practice  is  a 
generator  that  strives  to  transform  a  set  of  situations  into  some  other  set  deemed  more  favorable 
(as  judged  by  the  practice’s  criteria). 


Generative  Practice  Theory  embodies  a  theory  of  mimetic  learning  as  a  basis  for  the  formation  of 
new  practices.  Mimesis  is  a  process  of  observing  manifested  behavior,  then  building  a  practice 
that  can  produce  a  semblance  of  what  is  observed,  using  ingredient  practices  and  practice- 
elements  already  in  the  actor’s  repertoire.  Note  that  the  practice  is  the  generator  of  behavior  - 
and  so  actors  cannot  observe  the  practices  of  others  per  se.  Rather,  we  see  the  overt 
manifestation  of  the  execution  of  the  generator  (i.e.,  we  see  behavior,  not  the  generative 
competence).  Therefore  building  a  practice  is  a  kind  of  reverse-engineering  that  begins  with  a 
copy  of  some  behavior,  and  draws  on  the  existing  practices  of  the  actor  to  compose  one  that 
reproduces  the  observation.  This  process  tends  to  produce  an  imperfect  or  at  least  divergent 
capacity  than  the  one  observed,  at  least  initially.  Over  time,  the  social  system  will  tend  to  guide 
the  actor,  rewarding  and  punishing,  guiding,  and  exhibiting  behavior  that  is  used  to  develop  new 
observations,  so  that  the  practice  is  refined.  Individuals  and  organizations  employ  the  same 
mechanism. 


Practices  may  contain  other  practices.  For  example,  the  action  generator  A  may  itself  be  a  set  of 
embedded  practices  that  execute  concurrently,  or  may  be  a  program  that  imposes  some  degree  of 
sequential  operation  over  the  embedded  practices.  This  means  we  can  model  individuals, 
organizations,  and  other  social  forms  as  systems  of  practices.  A  rereading  of  the  propositional 
and  system  forms  shows  that  they  make  no  commitment  to  whether  the  practice  that  is  described 


5  Since  criteria  are  so  important  to  this  work,  we  offer  three  remarks  on  their  development.  First,  criteria  can  be  depicted  as  a 
partial  order  over  situations  -  consequents  in  the  situation  set  S+  are  preferred  to  prior  situations,  to  still-prior  situations,  and  so 
on  until  antecedents  in  the  situation  set  S"  are  reached.  (If  progress  is  not  unifonn,  then  we  are  afforded  multiple  opportunities  to 
observe  the  preference  in  action.)  Quantitative  relations  are  derived  by  consideration  of  quantitative  features  of  the  situations  in 
this  ordinal  ranking. 

Second,  if  we  can  learn  what  the  actor  monitors  -  events  that  signal  the  degree  of  satisfaction  of  the  criteria  -  then  we  have 
useful  evidence  for  the  property  that  is  being  tested,  and  so,  of  embodied  criteria.  It  is  in  the  nature  of  human  value-seeking 
behavior  that  we  aim  to  increase,  decrease,  or  preserve  some  quantity  or  state  of  affairs  in  our  actions.  Therefore,  measurements 
of  an  item  can  be  evaluated  for  the  purpose  of  increasing,  decreasing,  or  preserving  that  item,  its  source,  or  its  projected 
consequences. 

Third,  we  have  developed  applications  of  Generative  Practice  Theory  to  formalize  personality,  ideology,  and  culture.  Each  of 
these  entails  a  discipline  for  analyzing  variation  in  EBGs  to  identify  embodied  criteria.  Of  these,  the  criteria  embodied  by  the 
culture  are  generally  accessible  and  are  extremely  influential  for  the  actors  that  participate  in  the  culture.  In  other  words,  we  have 
access  to  very  useful  information  about  an  actor’s  criteria,  just  by  knowing  the  culture  that  the  actor  of  interest  (individual  or 
social)  inhabits. 
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represents  a  skill,  the  overall  behavior-generating  capacity  of  an  individual,  or  the  capacity  of 
some  other  social  fonn.  In  short,  the  practice  construct  is  sufficient  to  represent  individual  and 
social  behavior! 

Practice  Inter-dependence  -  Individual  and  Social  Actors 

Actors  -  individuals,  teams,  organizations,  institutions  -  are  bundles  of  inter-dependent 
practices.  Let  us  look  first  at  the  fine  structure  of  inter-dependence.  Consider  two  practices,  fifi 
and  n2,  where  fifi  is  defined  by  the  triple  (Si,  Ai,  Ci),  and  II2  by  (S2,  A2,  C2).  Si  is  the  set  of  all 
situations  that  the  criteria  C,  might  dictate  a  response  to.  As  a  result  of  activation  and  supervision 
by  Ci,  A;  creates  some  of  these  situations.  Practices  are  inter-dependent  whenever  the  situations 
S;  of  interest  to  one  practice  Tf  are  at  least  partly  created  by  some  other  practice  Llj,  resident  in 
the  same  or  some  other  actor.  Ultimately,  inter-dependence  reflects  a  coupling  among  the  criteria 
that  activate  and  manage  practices  -  since  criteria  manage  action  generators  to  create  satisfactory 
situations.  For  example,  if  part  of  S;  is  created  by  llj,  this  means  that  the  criteria  C,  respond  to 
and  seek  to  modify  situations  that  have  been  promoted  by  Cj  -  inducing  the  criterial  relation 
between  Cj  and  Ci,  through  S,  (via  A;). 


The  inter-dependence  of  practices  is  not  always  realized  in  behavior,  much  less  observed. 
Practices  are  coupled  if  their  criteria  are  potentially  coupled  -  that  is,  coupled  via  situations  that 
might  feasibly  be  created  by  the  action  generators  (and  in  light  of  ongoing  physical  processes). 
Therefore,  actual  inter-dependence  of  practices  far  exceeds  whatever  has  been  observed. 


The  existence  of  the  many  potential  interactions  among  practices  (and  so,  actors)  gives  rise  to  a 
type  of  field,  a  practice  field,  among  practices/actors.  Just  as  for  a  electromagnetic  field  for  any 
set  of  coupled  practices,  the  specification  of  conditions  for  a  subset  of  those  practices  constrains 
the  behavior  of  all  others  and  so  the  field  as  a  whole.  And  again,  just  as  we  see  in 
electromagnetic  fields,  the  dynamic  properties  of  executing  practices  (e.g.,  how  fast  they  suspend 
once  triggered)  constrains  the  rate  of  propagation  of  conditions  through  the  practice  field. 


We  have  discussed  how  practices  influence  one  another.  We  now  turn  to  the  two  large-scale 
types  of  inter-dependence  found  among  practices,  representing  ways  that  interactions  among 
practices  have  stabilized  for  some  period  of  time.  One  defines  the  cognitive  structure  of 
individual  humans,  the  other,  relations  among  the  practices  of  actors  in  an  organization  or  other 
social  fonnation. 


Individuals  are  systems  of  practices  that  are  prioritized  and  coordinated  within  a  supervisory 
actor  architecture  called  the  Ambiguity  Reduction  Architecture  -  the  ‘operating  system’  of  the 
individual.  The  architecture  treats  the  recurring  problem  individuals  have:  what  to  do  next. 
Ambiguity  reduction  abstracts  the  large  body  of  empirical  results  on  strategies  individuals  use  to 
focus  and  re-focus  attention,  resolve  conflicts,  select  among  optional  actions,  manage  interrupts, 
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suspend  and  re-activate  cognitive  and  other  tasks,  etc.  in  three  ways.  First,  there  are  structural 
relations  over  practices:  containment  or  nesting  relations,  mandated  sequences,  blocking  rules, 
etc.  Second,  for  those  practices  that  may  jointly  seek  to  execute,  there  are  control 
relations/policies  that  prioritize  and  schedule  or  suspend  their  execution.  As  needed,  the  actor 
may  deliberate  to  develop  for  fully  specialize  a  policy  for  current  conditions.  Third,  policies 
determine  the  portion  of  available  execution  resources  to  distribute  to  the  various  practices  that 
are  scheduled  to  execute. 


Control  policies  in  this  architecture  may  or  may  not  be  ‘knowledge  based’  -  actors  are  expected 
to  make  use  of  content-specific  control  or  choice-relevant  infonnation  if  available,  but 
ultimately,  may  legislate  which  practices  get  execution  resources  based  on  general  rules  (e.g., 
flip  an  n-sided  coin).  However,  all  control  policies  are  realized  by  making  execution  resources 
available  to  some  practices  (e.g.,  execution  resources  may  be  provided  to  any  subset,  or  to  a 
program  that  partially  or  totally  orders  a  subset  of  the  practices). 


Organizations,  and  other  social  forms  such  as  teams  and  institutions,  are  patterns  of  regular 
inter-dependencies  among  practices  that,  in  turn,  are  ‘carried’  by  individual  and  social  (multi¬ 
individual)  actors.  We  distinguish  three  types  of  inter-dependencies  among  practices  -  three 
ways  that  behavior  enacted  by  some  actors  may  influence  the  behavior  of  other  actors.  These  are 
resource  relations,  communication  relations,  and  role  relations. 


The  resource  relationship  among  practices  establishes  the  way  actors  inevitably  interact  with 
respect  to  physical  ingredients  -  physical  objects,  physical  settings,  and  infonnation.  Resource 
inter-dependencies  depict  how  practices  jointly  influence  one  another  as  they  create,  modify, 
share,  transport,  consume,  and  otherwise  manipulate  resources  (material,  information). 


The  structure  and  flow  of  resources  co-stabilizes  with  the  practices  that  appear  in  the  resource 
relation.  Criteria  dictate  distribution,  though  perhaps  not  uniquely.  However,  for  stable 
situations,  and  for  critical  resources,  one  to  a  few  stable  practice  fields  may  emerge,  and  once 
having  done  so,  stabilize  -  so  that  other  resource  relations,  and  other  more  general  practice 
relations,  adapt  under  the  assumption  of  the  resource  relation  as  it  stands. 


The  communication  relationship  establishes  the  flow  of  interpreted  information  through  actors. 
Communication  inter-dependencies  are  tendencies  to  focus  on,  manipulate/interpret,  seek,  share, 
and  be  advised  by  kinds  of  information  in  given  situations,  with  given  actors,  as  parts  of  ongoing 
activities.  A  communication  relation  is  present  provided  multiple  actors  are  capable  (in  their 
practices)  of  initiating,  receiving,  and  making  use  of  some  information,  and  provided  they  share 
a  tendency  to  actually  do  so  in  some  collection  of  situations. 
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Therefore,  a  communication  relation  is  not  present  simply  because  two  actors  happen  to  be 
connected  via  some  communication  medium  like  a  phone  or  e-mail  link  -  this  is  actually  a 
resource,  and  may  figure  in  a  resource  relation.  A  communication  relation  is  a  relation  among 
practices.  A  necessary  but  not  sufficient  condition  for  the  presence  of  a  communication  relation 
among  a  set  of  actors  is  that  they  are  all  capable  of  fonning,  sharing,  and  being  advised  by  some 
topic.  It  is  also  necessary  that  the  actors  are  actually  disposed  to  share  the  information  with 
others,  for  some  collection  of  situations  that  can  actually  arise.  Together,  these  conditions 
underwrite  a  communication  relation. 


As  with  resources,  communication  relations  tend  to  stabilize  in  the  organization  -  once  criteria 
finds  ways  of  satisfying  themselves,  their  action  generators  tend  to  be  used  in  like  situations,  and 
defended  until  blocked  or  otherwise  found  unsatisfactory.  For  example,  we  tend  to  come  to  rely 
on  particular  actors  for  particular  kinds  of  infonnation,  individuals  tend  to  develop  idiolects  and 
groups  tend  to  develop  dialects,  we  are  willing  to  share  information  or  engage  in  kinds  of 
communication  with  one  sort  of  person  but  not  another,  etc. 


We  remark  that  resource  and  communications  networks  are  a  minimal  abstraction  of  the  practice 
relation  we  describe.  They  depict  the  existence  of  an  influence  between  multiple  actors,  but 
suppress  the  space  of  potential  responses  one  actor  might  make  as  a  function  of  an  element  in  the 
space  of  actions  an  influencing  actor  might  take.6  E.g.,  the  many  responses  one  actor  might  make 
to  others  consuming  resources,  or  the  variable  interpretations  and  responses  an  actor  might 
develop  due  to  the  particular  pattern  of  infonnation  present  and  absent,  and  its  quality. 


Role  relationships  establish  the  orientation  actors  have  with  respect  to  one  another.  A  role  is  a 
systematic  response  an  actor  makes  to  a  class  of  situations  created  by  current  context  and, 
especially,  events  created  by  actors  in  coupled  roles  (coordinated  or  conflicting).  Therefore,  roles 
are  members  of  role  relations.  Roles  embody  established  kinds  of  interpretation,  including 
expectations  for  other  actors  and  for  likely  outcomes,  the  division  and  coordination  of  labor  or 
other  activity,  and  the  distribution  of  authority  and  responsibility  in  a  social  system.  Role 
relations  (e.g.,  patient/physician,  leader/follower,  adversary/adversary)  reside  in  the  way 
participants  tend  to  contribute  to  a  joint  activity  in  ways  that  enable  the  participants  as  a  whole  to 
jointly  move  things  forward.  They  make  effective  action  feasible  among  relative  strangers  (once 
situations  relevant  to  the  role  relation  are  brought  into  being,  and  recognized  by  one  or  more 
participants). 


6  Practice  inter-dependence  is  a  many-many  relation  -  each  practice  may  influence  multiple  others,  and  multiple  practices  may 
influence  one  practice.  Further,  the  product  of  a  practice  is  not  always  certain,  even  given  its  inputs  -  and  at  a  sufficiently  fine 
level  of  description,  the  enactment  will  entail  fundamental  uncertainties.  Therefore,  each  practice  induces  a  space  of  possible 
responses,  for  each  of  its  admissible  influencing  states.  In  turn,  admissible  input  states  are  generated  by  the  practice,  other 
practices  of  the  actor,  and  practices  of  other  actors  (interacting  in  the  physical  environment). 
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Roles  are  summaries  over  the  practices  of  actors  that  embody  the  role.  For  example,  our 
understanding  of  the  role  “physician”  derives  from  our  abstracting  over  the  behavior  of  many 
individuals  acting  as  health-care  providers.  It  is  useful  to  conceive  of  a  role  as  a  task  structure. 
Tasks  reflect  a  belief  system,  objectives  relevant  to  various  situations,  legitimate  ways  to 
undertake  the  task,  and  relations  to  other  tasks.  An  actors’  practices  instantiate  particular  skills 
for  recognizing  relevant  situations,  forming  relevant  interpretations,  setting  and  satisfying 
objectives,  etc. 


Roles  and  role  relations  structure  communication  and  resource  relations.  Since  most  behavior  is 
to  a  greater  or  lesser  degree  social  behavior  (behavior  that  is  influenced  by,  or  influential  for, 
other  actors),  most  behavior  is  structured  by  roles.  Communication  and  resource  utilization  are  in 
service  to  the  criteria  of  the  actor.  The  active  criteria  are  determined  by  the  currently-active 
practices,  and  so,  by  the  current  roles.  For  example,  topics  of  communication,  and  physical 
settings  and  ingredients,  are  oriented  by  the  role  -  departures  from  the  role-based  norms  are 
confusing,  seen  as  wrong  or  inappropriate,  or  in  a  few  cases,  humorous. 


A  role  is  realized  within  an  actor  as  a  system  of  practices  that  regularly  interacts  with  other 
actors’  practices  that  embody  the  complementary  role(s).  Therefore  the  criteria  embodied  in  the 
several  roles  must  be  coupled  -  moving  things  forward  for  some  or  all  participants,  or,  perhaps, 
moving  things  forward  for  some  participants,  while  thwarting  others’  ability  to  satisfy  their 
criteria  (adversarial  roles).  Criteria  (and  so  their  practices)  may  be  coupled  over  outcomes  - 
events  created  by  some  practices  are  ingredient  input  situations  for  other  practices.  Also,  criteria 
may  span  the  joint  activity  -  as  when  the  valued  outcome  is  a  group  or  system  outcome  (e.g., 
teams,  not  individuals,  win  the  soccer  match).  In  the  first  case,  participant  roles  guide  participant 
behavior  in  light  of  information  about  self/local  actions,  and  guide  interaction  at  the  boundaries 
of  the  practices.  In  the  second  case,  participant  roles  guide  participation  by  measuring 
global/shared  outcomes,  and  advising  individual  contributions  to  serve  the  creation  of  the  global 
outcome.  Both  kinds  of  criteria,  and  attendant  action  generators,  are  generally  present  in  a  role. 


As  things  proceed,  a  role  relation  achieves  its  central  objective  and  also  maintains  the  relation 
itself  -  stabilizing  the  practice  relation,  just  as  recurrent  resource-sharing  and  communication 
acts  stabilize  those  practice  relations.  For  example,  the  patient  and  the  physician  jointly  act  to 
produce  the  diagnosis,  treatment,  and  healing,  and  the  way  they  do  so  preserves  their  constituent 
roles.  In  a  care  episode,  the  criteria  that  lead  to  healing  are  satisfied  in  part  by  observing  the  role 
relation  -  and  so  the  roles  are  sustained  because  (in  relation)  they  are  generally  effective. 


Some  roles  are  taught.  For  example,  physicians  are  taught  the  physician/patient  relation  and  its 
tasks,  objectives  and  belief  system,  while  patients  and  physicians  experience  it  repeatedly  and,  as 
new  participants,  are  guided  by  the  responses  of  others  (novelty  and  error  are  limited).  Other 
relations  are  ‘absorbed’  by  the  stabilization  of  relations  in  activity,  rather  than  being  articulated 
and  taught  -  consider  the  roles  siblings  have  with  one  another  and  their  parents.  In  formal 
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organizations  (government,  business,  societies,  etc.)  there  is  some  of  each.  In  all  cases,  the 
various  parties  to  the  role  relation  create  a  pattern  of  initiatives  and  responses  that  lead  new 
participants  to  confonn  to  a  (quasi-)  stable  relation. 


For  each  of  resource,  communication,  and  role  inter-dependencies,  the  relationships  among 
participant  practices  determine  the  kinds  of  interactions  that  are  possible,  and  as  part  of  this, 
possible  products  that  are  shared  and  shareable.  Therefore,  “organization”  is  not  what  passes 
between  actors  -  e.g.,  the  physical  resource,  or  the  communication  topic.  Rather,  organization 
rests  with  situation/action/criteria  complexes  that  co-evolve,  stabilize  around,  and  ultimately 
determine  recurring  types  of  joint  actions.  This  is  easiest  to  see  with  role  relations  -  there  is  not 
necessarily  any  ‘thing’  that  passes  between  participants.  In  short,  ours  is  a  psychological  and 
social  view  of  organization  as  a  structured,  quasi-stable  deployment  of  adaptive  cognitive 
competence,  that  is,  of  practices. 


Foundations 

We  cannot  derive  the  practice  construct  from  first  principles.  Instead,  we  can  show  that  what  we 
know  limits  the  range  of  possibilities  for  what  can  count  as  a  generator  of  human  (individual  and 
social)  behavior.  We  develop  the  construct  from  this  point  of  view. 

Pertinent  Empirical  Facts 


•  Every  behavior  is  unique 

•  Cognition  is  bounded  =  we  are  finite 

o  We  are  not  capable  of  infinite  discrimination,  nor  of  perfect  control 

•  Likenesses  exist  among  events  and  event-relations 

o  And  so,  among  situations  and  behaviors  (which  are  event  complexes,  e.g.,  an 
event  set,  or  event  trajectory) 

o  We  generally  cannot  produce  a  final  definition  of,  say,  a  behavior,  but  we 
generally  can  say  whether  one  behavior  is  or  is  not  sufficiently  similar  to  another 

•  For  a  given  actor  and  epoch  (window  in  time),  we  may  observe  an  actor  managing  a 

behavior  in  a  regular  manner  -  provided  the  epoch  is  long  enough  to  observe  multiple 

manifestations.  In  particular: 

o  Similar  starting  situations  often  precede  similar  behaviors,  that  in  turn  produce 
similar  results 

o  For  a  given  behavior,  we  often  observe  a  wide  range  of  antecedent  situations  is 
controlled,  as  a  result  of  behavior,  to  a  tight  range  of  consequent  situations. 
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■  For  longer  epochs  we  may  observe  evolution  of  the  behavior.  E.g.,  we 
may  observe  the  range  of  starting  conditions  growing  and/or  the  variation 
in  the  consequents  being  reduced  -  i.e.,  increased  competence. 

o  Path-dependence  is  pervasive. 

■  An  actor’s  milieu  is  dynamic,  and  the  entry  points  for  behavior  operate 
over  a  period  of  time  -  rather  than  appearing  at  a  single  instant,  only. 

■  To  the  extent  that  the  nature  of  the  behavior  permits  it,  actors  can  begin  or 
re-enter  behavior  at  multiple  starting  points. 

o  We  observe  both  homeostatic  and  tra n s fo rmat i o n a  1/goa  1  -o r i cn ted  behavior 

•  As  actors  interact,  behaviors  manage  other  behaviors 

o  E.g.,  plan  execution  by  individual  and  social  actors 
o  E.g.,  competition,  coexistence,  collaboration 

•  Except  for  our  biological  endowment,  the  management  of  our  behavior  appears  to  be 
learned  through  interaction  with  the  physical  environment,  with  ourselves,  and  with 
our  social  environment. 

o  The  most  basic  mechanisms  seem  to  derive  from  our  ability  to  reflect  -  to 
produce  an  image  of  -  the  behavior  of  others.  Equivalently,  mimesis  is  the 
foundational  learning  mechanism. 

o  E.g.,  we  become  ourselves,  and  adapt  to  fill  a  variety  of  social  roles,  by 
confonning  to  all  these  others  -  to  mirror/mimic,  complement,  or  oppose  them. 

Developing  the  Practice  Construct 


•  We  postulate  a  generator  for  the  behavior  -  a  capacity,  embodied  by  (within)  each 
actor  that  produces  the  behavior 

•  The  set  of  potential  starting  situations  (for  any  behavior)  is  infinite.  Yet  all  actors  are 
finite. 

o  Therefore  the  generator  is  finite,  and  its  discrimination  is  finite. 

o  Therefore  the  generator  cannot  be  a  pre-existing  map  from  antecedent  situations 
to  an  open-loop/reflex  behavior 

o  Therefore  the  generator  must  have  the  form  of  a  capacity  respond  to  a  range  of 
antecedent  situations,  including  never-before-seen  ones 

•  We  identify  the  regular  management  of  antecedents  into  consequents  (i.e.  similar 
events  leading  to  similar  behaviors,  producing  similar  consequent  events)  with  the 
values  of  the  actor. 
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o  Equivalently,  behavior  inevitably  expresses  value,  and  so  a  value  construct  needs 
to  be  associated  with  every  level  of  behavior  production 

o  Values  are  relations  over  situations. 

■  Recall  that  the  actor  experiences  the  antecedents,  and  evidently  strives  to 
create  something  in  a  recurring  range  of  consequents. 

o  Values  may  be  qualitative  (logical,  symbolic)  or  metrical. 

■  Minimally,  a  value  is  a  partial  order  over  situations.  (Relevant  situations 
are  those  that  transpire  during  behavior,  and  those  projected  to  transpire 
absent  behavior.) 

■  Often  they  can  be  identified  with  conditions  that  the  actor  strives  to 
prevent,  undo,  decrease,  maintain,  increase,  or  create. 

■  In  some  cases,  a  measure  can  be  identified  that  is  extremized  during  the 
course  of  behavior.  In  this  case,  the  measure  orders  situations. 

•  A  finite  generator  with  the  above  properties,  and  sufficient  to  reproduce  the  empirical 
data,  can  be  developed  from  three  constituents  -  a  perceptual  system,  a  behavior- 
production  system,  and  a  criterial  system.  We  call  the  abstract  machine  with  these 
three  components  a  practice.7 

o  The  perceptual  system  maintains  a  dynamically-changing  situation,  whose 
contents  are  relevant  to  the  behavior-production  and  criterial  systems 

o  The  behavior-production  system  is  an  advisable/controllable  action-generation 
capacity 

o  The  criterial  system  monitors  the  contents  of  the  perceptual  system  and  generates 
signals  that  direct  the  ongoing  action  of  the  behavior-production  system. 

o  The  three  systems  operate  entirely  concurrently  (i.e.,  unlike  the  simpler  state- 
based  control  system  architecture  -  whose  plant  and  control  subsystems  both  tick 
ahead  to  the  same  clock). 

•  We  do  not  presume  all  behavior  is  generated  by  single  totalizing  practice  -  there  is  no 
evidence  for  one,  and  substantial  evidence  against  one.  Instead,  we  postulate  that 
actors  are  composed  of  many  practices. 

o  However,  we  have  no  need  to  suppose  that  the  form  of  the  practice  needs  to 
diverge  from  the  three  constituents  just  mentioned.  Equivalently,  any  specific 


7  The  construct  is  distinct  from  any  particular  embodiment  -  which  is  the  generator  of  some  particular  behavior.  If  necessary,  we 
could  refer  to  the  “practice  construct”  and  then  specific  practices.  Alternatively,  we  could  retain  “practice”  to  refer  only  to  the 
construct,  and  then  qualify  the  specific  ones  -  e.g.,  a  managing-a-meeting  practice.  Here,  we  allow  “practice”  to  refer  to  either, 
trusting  the  context  of  discussion  will  clarify  which  usage  is  intended. 
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behavior  generation  capability  can  be  instantiated  using  these  three  constituents 
of  the  practice  (construct). 

•  To  support  the  fact  that  behavior  manages  other  behavior,  we  require  a)  that  practices 
can  be  coupled  to  other  practices,  so  that  the  situations  produced  by  one  set  can  be 
coupled  to  the  perceptual  systems  of  another  set,  and  b)  that  practices  can  be 
recursively  embedded. 

o  Recursion  provides  for  general  control  structures  among  practices. 

■  E.g.,  an  outer  practice  that  designs  a  policy  in  a  situated  manner, 

communicates  it  to  an  embedded  practice,  which  installs  it  in  the 
embedded  criterial  system,  that  (recursively)  uses  the  policy  to  guide 
behavior  production 
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Appendix  B:  Sample  Practice  Schema 

We  illustrate  the  use  of  the  quasi-executable  specification  language. 

We  show  a  practice,  taken  from  a  scenario  we  invented  -  a  manhunt  for  a  key  figure  who  we 
never  see.  Instead,  we  see  the  effect  his  behavior  has  on  the  physical  and  especially  social 
environment  (i.e.,  we  do  not  observe  him,  but  we  observe  the  ripples  created  by  his  passage). 
Details  on  this  scenario  are  extensive  -  we  used  it  to  test  our  mapping  and  modeling  technology, 
as  well  as  this  specification  language,  and  so  a  version  of  the  scenario  exists  as  a  sample  project 
in  ACCORD.8 

This  particular  practice  shows  a  critical  choice  of  the  primary  character  -  the  “Key  Figure.”  He 
must  assess  the  threat  of  capture  that  he  faces  and  determine  his  next  move. 


practice  EscapeToSafeHaven 

{ 

/*  1 .  Information  Environment 

* 

*  Set  variable  names  are  always  of  PLURALS.  Other  variables  will  be  of  singular  form 

*/ 

set  Locations  =  {  "Settlement  A",  "Settlement  B",  "Settlement  C",  "CaveComplex  I", 
"CaveComplex  II",  "CaveComplex  III",  "CaveComplex  IV"  }; 
set  Activities  =  {  "Encamped",  "In-Transit"  }; 
set  Threatlntensities  =  {  "none",  "low",  "medium",  "high"  }; 
set  TimeToThreat  =  {  "unknown",  "days",  "hours",  "imminent-current"  }; 
set  WeaponTypes  =  {  "small  arms",  "SLMs",  "weaponized  sarin"  } 
set  EscapeDifficultyLevels  =  {  "low",  "medium",  "high"  }; 


8  The  details  of  this  scenario  are  available  upon  request. 
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String  KeyFigureResource  =  "small-arms,  weaponized  sarin,  radio,  cell  phone,  trucks, 
currency"; 

String  LowQualityTroopResource  =  "small-arms,  radio"; 

String  MediumQualityTroopResource  =  "small-arms,  radio,  trucks"; 

String  HighQualityTroopResource  =  "small-arms,  RPGs,  SLMs,  radio,  cell  phone,  trucks"; 

//  This  variable  is  used  to  monitor  and  keep  track  of  the  threat  the  KeyFigure  is  facing 
Threatlntensities  currentThreatlntensity; 

//  Used  to  keep  track  of  the  current  threat  that  KeyFigure  is  facing 
Boolean  NoThreat; 

NoThreat .  setV  alue(true) ; 

Boolean  AerialSurv; 

AerialSurv.setValue(false); 

Boolean  PatrollingTroopsNear; 

PatrollingTroopsNear.setValue(false); 

Boolean  StrikeForceNear; 

StrikeForceNear.setValue(false); 

//  Used  to  keep  track  of  the  time  until  the  threat  occurs 
TimeToThreat  timeUntilThreat; 

//  Used  to  show  the  KeyFigure's  escape  difficulty  level 
EscapeDifficultyLevels  escapeDifficulty; 

Real  estimatedTimeThreatContactProbability; 
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Object  escapeDifficultyProbability  {  Real  L,  Real  M,  Real  H  }; 
escapeDifficulty  Probability. L.setValue(O.O); 
escapeDifficulty  Probability. M.setValue(O.O); 
escapeDifficulty  Probability.H.setValue(O.O); 

//  These  store  the  percentage  of  each  type  of  troops  that  have  not  been  sacrificed 
Real  remainingLowQualityTroop; 
remainingLowQualityTroop.setValue(  1 .0); 

Real  remainingMediumQualityTroop; 
remainingMediumQualityTroop.setValue(  1 .0); 

Real  remainingHighQualityTroop; 
remainingHighQualityTroop.setValue(  1 .0); 

//  Whether  the  KeyFigure  has  successfully  escaped  to  selected  Safe  Haven. 

//  It  is  used  to  control  the  monitor's  execution 
Boolean  successfulEscapeToSafeHaven; 
successfulEscapeToSafeHaven(  false); 


/*  2.  Monitor 

*/ 

monitor  monitorThreatAndExecuteEscape 

{ 

monitorThreatAndExecuteEscape() 

{ 

Boolean  I  NoThreat  =  NoThreat.copyQ; 
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Boolean  l_AerialSurv  =  AerialSurv.copyO; 

Boolean  I  PatrollingTroopsNear  =  PatrollingTroopsNear.copy(); 

Boolean  l_StrikeForceNear  =  StrikeForceNear.copy(); 

Threatlntensities  lCurrentThreatlntensity  =  currentThreatlntensity.copyO; 

TimeToThreat  ITimeUntilThreat  =  timeUntilThreat.copy(); 

EscapeDifficultyLevels  lEscapeDifficulty  =  escapeDifficulty.copy(); 

ComputeThreatlntensity  complntensity  =  new  ComputeThreatIntensity(currenThreat, 
currentThreatlntensity); 


ComputeEstT  imeThreatC  ontactProb 

compThreatProb 

= 

new 

ComputeEstTimeThreatContactProb(); 

ComputeEscapeDifficultyLevel 

compEscapeLevel 

= 

new 

ComputeEscapeDifficultyLevel(); 

LeaveTroopsBehind  leaveTroops  =  new  LeaveTroopsBehind(); 

} 

void  startMonitor() 

{ 

while  (successfulEscapeToSafeHaven  ==  false) 

{ 

par 

{ 

//  These  two  calls  run  concurrently 
if  (l  CurrentThreat  !=  currentThreat) 
complntensity. Main(); 

if  (l  CurrentThreatlntensity  !=  currentThreatlntensity) 
compThreatProb.Main(); 

} 
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//  Successive  calls 

if  (ITimeUntilThreat  !=  timeUntilThreat) 
compEscapeLevel.Main(); 
if  (l  EscapeDifficulty  !=  escapeDifficulty) 
leaveTroops.Main(); 

} 

ExitToSafeHaven(compIntensity,  compThreatProb,  compEscapeLevel,  leaveTroops); 

} 

} 

void  Relocate() 

{ 

//  Does  the  relocation  of  KeyFigure  and  troops 

} 


/*  *** 

*  This  is  a  stand-alone  procedure  to  illustrate  procedure  construction. 

*  It  body  can  be  embedded  in  the  above  monitor  as  well 

*/ 

void  ExitToSafeHaven(ComputeThreatIntensity  complntensity, 

ComputeEstTimeThreatContactProb  compThreatProb, 

ComputeEscapeDifficultyLevel  compEscapeLevel,  LeaveTroopsBehind 

leaveTroops) 

{ 

//  Does  any  appropriate  clean-up  here 
complntensity. Kill(); 
compThreatProb. Kill(); 
compEscapeLevel. Kill(); 
leaveTroops. KillQ; 
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//  And  additional  clean-up  here  if  needed. 


} 


/*  3.  Activity  Generator 

*/ 

activityGen  ComputeThreatlntensity 

{ 

//  Local  reference  of  parameter  list 
ThreatTypes  theCurrentThreat; 
Threatlntensities  theCurrentThreatlntensity; 


ComputeThreatIntensity(ThreatTypes  currentThreat,  Threatlntensities 

currentThreatlntensity) 

{ 

theCurrentThreat  =  currentThreat; 
theCurrentThreatlntensity  =  currentThreatlntensity; 

} 

//  This  activity  generator  continuously  monitors  and  modifies  the  currentThreatlntensity 
"directly" 

//  There  is  no  need  for  a  local  copy  of  the  parameter  list 

// 

//  If  but  there  the  need  for  a  local  copy  of  the  parameter  list,  then  the  function  Initialize() 

//  kicks  in  to  initialize  the  value  variable(s),  using  copy() 

void  Initialize(ThreatTypes  currentThreat,  Threatlntensities  currentThreatlntensity) 


55 


{ 


//  localCurrentThreat  =  currentThreat.copy(); 

//  localCurrentThreatlntensity  =  currentThreatIntensity.copy(); 

} 

void  Main() 

{ 

if  (StrikeForceNear  ||  (AerialSurv  &&  PatrollingTroopsNear)) 
theCurrentThreatIntensity.setValue("high"); 
else  if  (AerialSurv  ||  NoThreat) 

theCurrentThreatIntensity.setValue("low"); 
else  if  (PatrollingTroopsNear) 

theCurrentThreatIntensity.setValue("medium"); 

} 

void  Pause() 

{ 

} 

void  Resume() 

{ 

} 

void  Kill() 

{ 

theCurrentThreat  =  null; 
theCurrentThreatlntensity  =  null; 
isKilled  =  true; 

/*  The  following  may  be  a  self-generated  call.  User  does  not  need  to  define  it.  If  the 
assumption 

*  is  correct,  it  would  the  call  to  the  kill()  method  of  this  thread  object. 

*/ 
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disposeQ; 


} 


} 


//  Since  this  activity  generator  does  not  behave  like  a  continuation,  we  can  safely  ignore  the 
local  copy 

//  of  the  parameter  list.  Also,  since  the  generator  modifies  the  triggering  event(s)  directly,  we 
can 

//  completely  manipulate  them  through  the  use  of  globals. 
activityGen  ComputeEstTimeThreatContactProb() 

{ 


void  Initialize() 

{ 

} 

void  Main() 

{ 

Real  totalProb; 
totalProb.setValue(  1 .0); 

if  (No  Threat) 

{ 

if  ( timeUntilThreat  ==  "days") 
totalProb.setValue(0.8  *  totalProb); 
else  if  (timeUntilThreat  ==  "hours") 
totalProb. setValue(0.2  *  totalProb); 
else  if  (timeUntilThreat  ==  "imminent-current") 
totalProb .  setV  alue(0 . 0); 

} 


57 


if  (AerialSurv) 

{ 


if  ( timeUntilThreat  ==  "days") 
totalProb.setValue(0.6  *  totalProb); 
else  if  (timeUntilThreat  ==  "hours") 
totalProb. setValue(0.4  *  totalProb); 
else  if  (timeUntilThreat  ==  "imminent-current") 
totalProb .  setValue(0 . 0) ; 

} 

if  (PatrollingTroopsNear) 

{ 

if  ( timeUntilThreat  ==  "days") 
totalProb. setValue(0.2  *  totalProb); 
else  if  (timeUntilThreat  ==  "hours") 
totalProb. setValue(0. 6  *  totalProb); 
else  if  (timeUntilThreat  ==  "imminent-current") 
totalProb. setValue(0.2  *  totalProb); 

} 

if  (StrikeForce) 

{ 

if  ( timeUntilThreat  ==  "days") 
totalProb .  setValue(0 . 0) ; 
else  if  (timeUntilThreat  ==  "hours") 
totalProb. setValue(0.2  *  totalProb); 
else  if  (timeUntilThreat  ==  "imminent-current") 
totalProb.setValue(0.8  *  totalProb); 

} 

estimatedTimeThreatContactProbability.setValue(totalProb); 
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} 

void  Pause() 

{ 

} 

void  Resume() 

{ 

} 

void  Kill() 

{ 

/*  The  following  may  be  a  self-generated  call.  User  does  not  need  to  define  it.  If  the 
assumption 

*  is  correct,  it  would  the  call  to  the  kill()  method  of  this  thread  object. 

*/ 

dispose(); 

} 

} 

activityGen  ComputeEscapeDifficultyLevel() 

{ 

void  Initialize() 

{ 

} 

void  Main() 

{ 

if  (currentThreatlntensity  ==  "high") 

{ 

if  (timeUntilThreat  ==  "days") 
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{ 

escapeDifficultyProbability  .M .  setV  alue(  .5); 
escapeDifficultyProbability.H.setValue(.5); 

} 

else  if  (timeUntilThreat  ==  "hours") 

{ 

escapeDifficultyProbability. H.setValue(  1 .0); 

} 

else  if  (timeUntilThreat  ==  "imminent-current") 

{ 

escapeDifficultyProbability.H.setValue(  1 .0); 

} 

} 

else  if  (currentThreatlntensity  ==  "medium") 

{ 

if  (timeUntilThreat  ==  "days") 

{ 

escapeDifficultyProbability. M.setValue(  1 .0); 

} 

else  if  (timeUntilThreat  ==  "hours") 

{ 

escapeDifficultyProbability  .M .  setV  alue(0 . 5); 
escapeDifficultyProbability.H.setValue(0.5); 

} 

else  if  (timeUntilThreat  ==  "imminent-current") 

{ 

escapeDifficultyProbability.H.setValue(  1 .0); 

} 
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} 

else  if  (currentThreatlntensity  ==  "low") 

{ 

if  (timeUntilThreat  ==  "days") 

{ 

escapeDifficultyProbability  .L .  setV  alue(  1.0); 

} 

else  if  (timeUntilThreat  ==  "hours") 

{ 

escapeDifficultyProbability  .L .  setV  alue(0 . 5); 
escapeDifficultyProbability.M.setValue(0.5); 

} 

else  if  (timeUntilThreat  ==  "imminent-current") 

{ 

escapeDifficultyProbability.  M.setValue(  1 .0); 

} 

} 

} 

void  Pause() 

{ 

} 

void  Resume() 

{ 

} 

void  Kill() 

{ 
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/*  The  following  may  be  a  self-generated  call.  User  does  not  need  to  define  it.  If  the 
assumption 

*  is  correct,  it  would  the  call  to  the  kill()  method  of  this  thread  object. 

*/ 

dispose(); 

} 

} 

activityGen  LeaveTroopsBehind() 

{ 


void  Initialize() 

{ 

} 

void  Main() 

{ 

if  (escapeDifficulty  ==  "high") 

{ 

remainingLo  wQuality  T  roop .  setValue(O) ; 

remainingMediumQuality Troop .  setV alue(remainingMediumQualityT roop  /  2); 
remainingHighQuality Troop .  setV alue(remaingHighQualityT roop  /  2); 

} 

else  if  (escapeDifficulty  ==  "medium") 

{ 

remainingLowQualityTroop.setValue((remainingLowQualityTroop  *  1)  /  4); 
remainingMediumQualityTroop.setValue(remainingMediumQualityTroop  /  2); 
//  remainingHighQualityTroop  is  not  sacrificed 
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} 

else  if  (escapeDifficulty  ==  "low") 

{ 

remainingLowQualityT roop .  setV alue(remainingLowQualityT roop  /  2); 
remainingMediumQualityTroop.setValue((remainingMediumQualityTroop  *9)/  10); 

//  remainingHighQualityTroop  is  not  sacrificed 

} 

} 

void  Pause() 

{ 

} 

void  Resume() 

{ 

} 

void  Kill() 

{ 

/*  The  following  may  be  a  self-generated  call.  User  does  not  need  to  define  it.  If  the 
assumption 

*  is  correct,  it  would  the  call  to  the  kill()  method  of  this  thread  object. 

*/ 

dispose(); 

} 

} 

} 
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Appendix  C:  Quasi-Executable  Specification  of  a  Human-Systems 
Simulation  Experiment 

Simulation  scenario 


The  simulation  is  a  man-hunting  scenario  in  Afghanistan.  The  target  of  the  man-hunting  is  a 
certain  key  figure,  KF,  that  attempts  to  exit  the  country  by  crossing  the  border  with  Pakistan.  KF 
is  a  drug  lord  that  has  been  advised  by  his  informants  and  associates  in  the  government  to  exit 
the  country  and  keep  a  low  profile. 


KF’s  exit  strategy  is  to  attempt  to  reach  Pakistan  by  land  using  the  Southern  routes.  The  southern 
border  of  Afghanistan  with  Pakistan  is  particularly  porous,  and  KF  has  a  great  network  of  passes 
and  secondary  roads  to  choose  from  while  selecting  the  route.  KF  plans  to  gather  a  small  convoy 
of  about  three  cars  and  some  scouters.  Although  the  convoy  is  heavily  armed,  KF  seeks  to  avoid 
as  much  as  possible  any  engagement  with  border  guards,  police,  or  coalition  forces. 


On  the  route  to  Pakistan,  KF  maintains  several  safe  houses,  often  located  in  villages  where  the 
population  shares  his  ethnicity  and  is  willing  to  give  him  support  and  shelter.  However,  KF’s 
stay  in  a  safe  house  cannot  be  too  long:  the  longer  he  stays  in  Afghanistan,  the  more  likely  some 
coalition  forces  will  locate  and  capture  him. 


The  coaltion  forces  know  the  area  to  search  for  KF  and  has  a  network  of  sensors  to  locate  him 
and  informants  to  tip  off  about  his  location.  In  the  operation,  the  coalition  forces  receive  support 
from  the  Afghan  police  and  border  guards.  However,  they  are  concerned  about  the  lack  of  proper 
equipment  and  about  the  corruption  among  the  border  guards  and  police.  In  fact,  KF  knows  that, 
although  he  is  unlikely  to  be  successful  in  bribing  or  defeating  some  coalition  forces,  he  is  sure 
that  the  odds  of  success  are  substantially  higher  if  he  encounters  police  or  border  guards. 


64 


Simulation  Parameters 


Time  and  Execution 


The  simulation  engine  is  responsible  to  run  a  clock.  We  define  a  certain  amount  of  time  ticks 
(say  2000)  and  set  current  time  to  zero  and  set  end  of  simulation  flag  to  zero. 


For  example,  we  have: 


Integer  CurrentTime  =  0; 

Integer  EndTime  =  2000; 

Boolean  EndSimulation;  EndSimulation.setValue  (false); 


Actors 

The  simulation  contains  a  certain  amount  of  actors,  including  the  key  figure  and  the  “good 
guys”.  For  example,  we  may  specify  4  actors  for  the  simulation: 


Integer  NumActors  =  5; 


There  is  only  one  type  of  key  figure  actor,  but  three  types  of  good  guys  actors.  E.g., 
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String  Actor_Type  =  “key  figure”; 


//  Actor  needs  to  have  the  key  figure  practices 


String  Actor_Type  =  “coalition”;  //  type  of  good  guy 

String  Actor_Type  =  “police”;  //  type  of  good  guy 

String  Actor_Type  =  “border  guard”;//  type  of  good  guy 

Each  actor  has  a  name.  E.g., 

String  Actor_Name  =  “key  figure”; 

String  Actor_Name  =  “coalition  1”; 

String  Actor_Name  =  “police  1”; 

String  Actor_Name  =  “police  2”; 

String  Actor_Name  =  “border  guard  1”; 

For  each  type  of  actor,  except  for  “key  figure”,  we  define  three  sizes,  “large”,  “med”,  “small”. 
We  assign  an  actor  size  for  each  actor.  E.g.,: 


String  Actor_Name  =  “large”; 
String  Actor_Name  =  “med”; 
String  Actor_Name  =  “small”; 
String  Actor_Name  =  “small”; 


//  for  “coalition  1” 

//  for  “police  1” 

//  for  “police  1” 

//  for  “border  guard  1” 
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Speed 


For  each  actor,  we  assign  two  speed  parameters,  a  regular  speed  and  a  fast  speed,  according  to 
the  following  table: 


Actor  Type 

RegularSpeed 

FastSpeed 

Key  Figure 

36 

60 

Coalition 

30 

72 

Police 

24 

42 

Border  guard 

12 

36 

E.g., 

for  “key  figure” 

Real  RegularSpeed  =  36; 
Real  FastSpeed  =  60; 

for  “coaltion  1” 

Real  Regular  Speed  =  30; 
Real  Fast_Speed  =  72; 
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Sensor  Degeneration  Rates 


For  each  actor,  the  probability  to  detect  an  opponent  depends  on  the  distance  D  between  the 
actor  and  the  opponent.  The  longer  the  distance,  the  less  likely  that  the  detection  will  occur 

Range  of  100%  chance  detection:  D  <  rangelOO', 

Range  of  50%  chance  of  detection:  range  lOO  <=  D  <  range_50 
Range  of  25%  chance  of  detection:  range_50  <=  D  <  range_25 
Range  of  0%  chance  of  detection:  D  >  range_25 


We  define  the  degeneration  rates  according  to  the  values  we  set  for  range_25,  range_50,  and 
range  lOO.  We  specify  the  following  table  for  the  sensor  degeneration  rates: 


Actor  Type 

RangelOO 

Range_50 

Range_25 

Key  Figure 

5 

9 

13 

Coalition 

5 

9 

13 

Police 

5 

7 

9 

Border  guard 

5 

6 

7 

E.g., 

-  For  “key  figure” 
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Real  Range  lOO  =  5; 


Real  Range_50  =  0; 

Real  Range_25  =  13; 

Phone  Call  Probability 

For  each  actor,  there  is  an  probability  that  the  actor  may  receive  a  phone  call  with  a  precise 
location  of  an  opponent.  We  specify  the  following  table  for  the  phone  call  probabilities: 


Actor  Type 

Phone_  CallProbabilit 

y 

Key  Figure 

0.4 

Coalition 

0.3 

Police 

0.01 

Border  guard 

0.01 

Threat  Tolerance  for  Key  Figure 


The  key  figure  has  several  parameters  that  indicate  their  policy  for  threat  tolerance.  These 
variables  are: 
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ThreatThreshold:  maximum  amount  of  threat  that  the  key  figure  tolerates 

Num  Cycles:  number  of  threat  information  updates  required  to  increse  threshold  for  threat 
tolerance 

ThresholdChangeRate:  percentage  increase  each  time  the  key  figure  decides  to  change 
threshold 


We  initiate  these  parameters  with  the  following  values: 


Real  Threat  Threshold  =  0.25; 
Integer  Num_Cycles  =  3; 

Real  Threshold  Change  Rate  =1.1; 


Location  Estimation  Decay  Rates  for  Good  Guys 

The  location  of  the  key  figure  is  given  by  a  estimate  of  its  position  plus  an  estimation  range.  At 
the  time  the  actor  receives  the  position  of  the  key  figure,  the  estimation  range  is  zero  (i.e.  the 
position  is  an  accurate  estimation  of  its  location).  However,  as  times  passes,  the  location  become 
less  accurate  as  the  estimation  range  increases  (i.e.  the  location  is  somewhere  in  the  area 
centered  in  the  last  reported  position  within  a  certain  radius.  The  decay  rates  represent  the  rate  of 
that  this  radius  increase  per  time  tick.  We  specify  the  following  table  for  the  actors: 


Actor  Type 

DecayRates 

Coalition 

2 

70 


Police 


3 


Border  guard  5 


E.g., 


for  “coalition  1” 
Real  Decay  Rate  =  2; 


Data  Structures 


TerrainMap 


TerrainMap  the  “terrain  map”  of  the  scenario,  i.e.,  the  list  of  the  possible  ways  that  links  any 
two  points  in  the  map. 


There  are  two  major  elements  in  the  map: 


-  waypoints  (vertices) 
roads  (edges) 


Terrain  Map  is  a  collection  of  roads,  each  road  with  a  start  waypoint,  an  end  waypoint,  and  a 
length. 
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Format  of  a  TerrainMap  element:  (roadid,  start  waypoint,  end  waypoint,  road  length) 

With  this  format,  a  a  certain  road  with  <road_id>  connects  two  points,  <start_waypoint>  and 
<end_waypoint>,  and  has  has  lenght  <road_length>. 

In  the  simulation,  create  your  own  terrain  map.  One  example  is  given  below. 


Vector  Terrain  Map  = 


((roadl, 

“origin”,  “wpl”, 

3), 

(road2, 

“wpl”,  “wp2”, 

15), 

(road3, 

“wp2”,  “safe  house  1”, 

2), 

(road4, 

“wpl”,“wp3”, 

10), 

(road5, 

“wp2”,  “wp3”, 

6), 

(road6, 

“wpl”,  “wp4”, 

12), 

(road7, 

“wp4”,  “safe  house  2”, 

4), 

(road8, 

“wp3”,“wp5”, 

14), 

(road9, 

“wp2”,  “wp5”, 

20), 

(road  10, 

“wp5”,  “wp6”, 

8), 

(roadl  1, 

“wp6”,  “wp7”, 

8), 

(road  12, 

“wp6”,  “final  destination”, 

7), 

(road  13, 

“wp5”,  “final  destination”, 

11), 
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(road  14, 


“wp7”,  “final  destination”,  13)) 


Aiig_  TerrainMap 


AugTerrainMap  is  an  augmented  version  of  Terrain  Map. 


In  the  augmented  map,  each  road  has  two  entries,  the  original  entry  with  edge  direction  = 
“forward”  and  a  second  entry,  where  we  switch  start_waypoint  and  end_waypoint  and  have 
edge_direction  =  “backward”; 


This  table  is  defined  simply  to  facilitate  the  use  of  Dijikstra  algorithm  to  compute  the  shortest 
path  in  a  directed  graph  (with  vertices  and  edges).  In  this  case,  assigning  a  direction  to  a  road 
makes  it  an  edge  (a  directed  link). 


Format  of  Aug  Terrain  Map  element:  (road  id,  start  waypoint,  end  waypoint,  road  cost, 
edge_direction) 


Using  Terrain_Map  above,  we  have  the  respectve  augmented  map. 


Vector  Aug  Terrain  Map  = 

((roadl,  “origin”,  “wpl”, 

3,  “forward”), 

(road2,  “wpl”,“wp2”, 

15,  “forward”), 
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(road3, 

“wp2”, 

“safe  house  1”, 

2, 

“forward”), 

(road4, 

“wpl”, 

“wp3”, 

10, 

“forward”), 

(road5, 

“wp2”, 

“wp3”, 

6, 

“forward”), 

(road6, 

“wpl”, 

“wp4”, 

12, 

“forward”), 

(road7, 

“wp4”, 

“safe  house  2”, 

4, 

“forward”), 

(road8, 

“wp3”, 

“wp5”, 

14, 

“forward”), 

(road9, 

“wp2”, 

“wp5”, 

20, 

“forward”), 

(road  10, 

“wp5”, 

“wp6”, 

8, 

“forward”), 

(road  1 1 , 

“wp6”, 

“wp7”, 

8, 

“forward”), 

(road  12, 

“wp6”, 

“final  destination”, 

7, 

“forward”), 

(road  13, 

“wp5”, 

“final  destination”, 

11, 

“forward”), 

(road  14, 

“wp7”, 

“final  destination”, 

13, 

“forward”), 

(road  1 , 

“wpl”, 

“origin”, 

3, 

“backward”), 

(road2, 

“wp2”, 

“wpl”, 

15, 

“backward”), 

(road3, 

“safe  house  1”, 

“wp2r 

) 

? 

2,  “backward”), 

(road4, 

“wp3”, 

“wpl”, 

10, 

“backward”), 

(road5, 

“wp3”, 

“wp2”, 

6, 

“backward”), 

(road6, 

“wp4”, 

“wpl”, 

12, 

“backward”), 

(road7, 

“safe  house  2”, 

“wp4r 

» 

4,  “backward”), 

(road8, 

“wp5”, 

“wp3”, 

14, 

“backward”), 

(road9, 

“wp5”, 

“wp2”, 

20, 

“backward”), 

(road  10, 

“wp6”, 

“wp5”, 

8, 

“backward”), 
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(road  1 1 , 

“wp7”,  “wp6”, 

8, 

“backward”), 

(road  12, 

“final  destination”, 

“wp6”, 

7, 

“backward”), 

(road  13, 

“final  destination”, 

“wp5”, 

11, 

“backward”), 

(road  14, 

“final  destination”, 

“wp7”, 

13, 

“backward”),); 

WaypointsList 

Waypoints  List  is  a  collection  of  all  waypoints  (vertices)  of  the  TerrainMap.  Each  waypoint 
has  format  of  string.  Observe  that  the  origin,  destination,  and  safe  houses  are  all  waypoints. 


For  example,  the  terrain  map  above  contains  the  following  waypoints. 


Vector  Waypoints_List  =  (“origin”,  “final  destination”,  “safe  house  1”,  “safe  house  2”,  “wpl”, 
“wp2”  “wp3”,  “wp4”,  “wp5”,  “wp6”,  “wp6”,); 


SafeHousesList 

SafeHousesList  is  a  subset  of  Waypoints  List  containing  a  list  of  all  safe  houses  in  the 
scenario,  including  the  origin  and  final  destination. 


For  example,  the  terrain  map  above  contains  the  following  safe  houses. 


Vector  Safe_House_Lists  =  (“origin”,  “final  destination”,  “safe  house  1”,  “safe  house  2”); 
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Final  Destination 


A  string  containing  the  final  destination  node  for  the  key  figure.  In  the  example,  the  final 
destination  is  “final  destination” 


String  Final  Destination  =  “final  destination”; 


Current  Position 


CurrentPosition  represents  the  current  position  of  the  actor  in  the  map. 


In  our  system  of  coordinates,  a  position  is  expressed  in  terms  of  the  road  where  the  point  is 
located  and  the  distance  of  that  point  to  the  start  waypoint  (i.e.,  the  road  position). 


Format:  (road  id,  road_position) 


E.g.,  (road2,  3)  refers  to  a  position  in  road2  located  3  km  from  “wpl” 


In  the  simulation,  we  initiate  the  current  positions  for  the  actors  as  follows: 


Key  Figure:  Vector  Current  Position  =  (roadl ,  0) 
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Good  Guys:  Vector  CurrentPosition  =  (randomRoad  (),  randomPosition  ()) 


where  the  functions: 


Vector  random  Road  ()  randomly  select  a  road  from  roadl  to  road  14 

Vector  random  Position  ()  randomly  select  a  position  between  0  and  the  lenght  of  the 
selected  road 


Vector  ran  dont_  Position_  ln_  M up  ()  {} 


returns  a  position  (road  id,  road_position)  randomly  selected  from  those  available  in  the  map. 
We  simply  randomly  select  a  road  (from  roadl  to  road  14)  and  randomly  select  a  position  (from  0 
to  the  lenght  of  the  road). 


Next  Destination 


Next  Destination  contains  the  position  of  the  next  destination  of  a  given  actor.  In  the  simulation, 
we  initiate  Next  Destination  with  the  actor’s  current  position. 


Vector  Next  Destination  =  Current  Position; 


Current  Route 
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CurrentRoute  is  a  sequence  of  directed  roads  that  link  two  positions  in  TerrainMap,  the 
CurrentPosition  and  the  Next  Destination.  Each  element  of  Route  contains  a  road  and  a 
direction. 


Format  of  an  element  of  Route:  (roadid,  roaddirection). 


We  define  two  road  directions: 


“forward”,  that  specifies  the  direction  from  start  waypoint  to  end  waypoint 
“backward”,  that  specifies  the  direction  from  end  waypoint  to  start  waypoint 


For  example,  the  following  route  links  “origin”  to  “wp2” 


Current_Route  =  ((roadl,  “forward”),  (road4,  “forward”),  (road5,  “backward”)) 


Notice  that  Current  Position  must  be  a  position  in  roadl  (first  route  element)  and 
Next_Destination  must  be  a  position  in  road5  (last  route  element). 


In  the  simulation,  initiate  Current  Route  as  follows: 


Key  Figure:  Vector  Current  Route  =  (roadl,  “forward”) 

Good  Guys:  Vector  Current  Route  =  (random  Road  (),  “forward”) 
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Ground Truth_  Table 

Ground  Truth  Table  contains  of  the  real  position  for  each  actor  at  each  time  tick  of  the 
simulation. 


Format  of  each  element:  (threat  id,  actorname,  actor_position).  We  iniate  the  table  with  the 
Current  Position  of  the  each  actor  when  they  were  created.  For  example, 


Vector  Ground  Truth  Table  = 


((not_threat,  “key  figure”,  (roadO,  0)), 


(threat  1, 
(threat2, 
(threat3, 
(threat3, 


‘coalition  1”,  (road5,  1)), 


‘police  1”,  (road3,  4)), 

‘police  2”,  (road7,  10), 


‘police  2”,  (road7,  10)); 


//  randomly  selected  positions 
//  randomly  selected  positions 
//  randomly  selected  positions 
//  randomly  selected  positions 


ThreatMap 

ThreatMap  is  used  by  the  key  figure  to  track  the  position  of  each  good  guy  at  each  time  tick.  In 
addition  to  the  threat  identification  and  position,  each  element  of  Threat  Map  contains  the 
location  range  for  the  position  estimate  and  also  the  type  and  size  of  the  threat  (good  guy). 
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Format  of  an  element:  (threat  id,  threat  type,  threat  size,  threat_position,  positionrange). 


We  initiate  the  simulation  with  the  initial  position  of  the  threats  but  assign  a  large  number  for 


position  range  (say,  50).  For  example,  we  may  initiate  the  table  as  follows: 

Vector  Threat  Map  = 

((not_threat, 

“key  figure”,  “1”, 

(roadO,  0),  50), 

(threat  1, 

“coalition”, 

“large”,  (road5,  1),  50), 

(threat2, 

“police”, 

“med”,(road3, 4),  50), 

(threat3, 

“police”, 

“small”,  (road7,  10),  50), 

(threat3, 

“police”, 

“small”,  (road7,  10),  50); 

ThreatSensorData 

ThreatSensorData  contains  a  list  of  messages  informing  the  current  position  for  several 
threats,  as  reported  by  its  sensors. 

Format  of  an  element  (threat  id,  threat_position) 

Threat  Risk  Table 
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Associate  type  and  size  of  threat  with  its  defeatability  and  bribability 


Format  of  an  element  (t  type,  t_size,  defeat,  brib).  For  example, 


Vector  Threat  Risk  Table  = 


((“Coalition”, 

“Large”, 

0.01, 

0.01), 

(“Coalition”, 

“Med”, 

0.02, 

0.01), 

(“Coalition”, 

“Small”, 

0.03, 

0.01), 

(“Police”, 

“Large”, 

0.4, 

0.5), 

(“Police”, 

“Med”, 

0.5, 

0-5), 

(“Police”, 

“Small”, 

0.6, 

0.5), 

(“Border  guard”, 

“Large”, 

0.7, 

0.8), 

(“Border  guard”, 

“Med”, 

0.8, 

0.8), 

(“Border  guard”, 

“Small”, 

0.9, 

0.8)); 

In  this  case,  the  key  figure  perceives  0.4  probability  to  defeat  a  large  police  and  0.5  probability 
to  bribe  it.  On  the  other  hand,  the  key  figure  perceives  only  a  0.02  to  defeat  a  medium  coalition 
and  0.01  to  bribe  it. 


Algorithms 
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Route  Selection 


To  select  a  route  between  two  positions,  we  use  Dijikstra  algorithm  for  shortest  path 
computation.  The  Dijikstra  algorithm  takes  a  collection  of  Vertices  (nodes),  a  collection  of 
Edges  (directed  links)  connecting  the  vertices,  and  the  cost  of  each  edge  as  inputs.  It  returns  the 
sequence  of  Edges  from  a  given  starting  vertex  to  a  given  end  vertex  that  minimizes  the  total 
costs  of  the  edges  traversed. 


In  other  to  match  the  inputs  of  the  Dijikstra  algorithm,  we  need  to  perfonn  the  following 
adaptations: 


Origin  and  Destination 


In  Dijikstra  algorithm,  the  start  and  end  points  are  vertices.  However,  in  our  system  of 
coordinates,  a  starting  or  ending  point  can  be  a  position  in  the  middle  of  an  edge  (road).  In  this 
case,  we  perform  the  following  operations 


Convert  the  starting  and  ending  points  into  two  new  vertices  (start_v  and  end_v) 

Each  of  these  new  vertices  represents  a  point  that  partition  their  respective  road  into  two  road 
sections:  a  section  from  the  vertice  to  the  start  waypoint  of  the  road  and  a  section  from  the 
vertice  to  the  end  waypoint 

Vertices 

Given  that  the  start  and  end  points  are  re-defined  as  new  vertices,  we  define  the  following  set  for 
the  vertices 


82 


Vector  Vertices  =  Waypoints_List  +  “start_v”  +  “end_v”; 


Notice  that  we  don’t  need  to  add  “start_v”  (or  “end_v”)  if  they  are  already  waypoints. 


Edges 


Edges  is  based  on  Terrain  Map  that  lists  a  collection  of  roads  connecting  two  points.  However, 
an  edge  is  a  directed  link,  so  we  need  to  define  a  direction  for  the  road.  Thus,  we  define 
AugTerrainMap  for  this  purpose  (see  previous  section). 


In  addition  to  the  direction,  we  add  some  additional  entries  in  Aug  Terrain  Map  that  correspond 
to  the  edges  representing  the  new  road  sections  that  were  created  when  we  added  the  new 
vertices. 


Costs 


The  costs  are  associated  with  each  road,  regardless  of  their  direction.  We  have  two  types  of 
costs,  depending  of  what  type  of  criteria  we  use  for  the  Dijikstra  algorithm. 


For  a  simple  shortest  path  computation,  we  use  the  length  of  the  road  (or  the  road  section)  as  the 
cost. 


For  the  “safest”  path,  we  use  a  score  system  that  scores  the  road  (or  road  section)  according  to  its 
length  and  according  to  the  type  and  size  of  threat  located  in  that  road  (or  road  section). 
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Road  scoring 


Roads  are  scored  in  terms  of  their  cost.  As  mentioned  before,  the  cost  of  a  road  (or  road  section) 
may  be  simply  its  length.  More  general,  we  may  score  the  road  as  a  function  of  its  length  and  the 
threats  located  on  it. 


Thus,  in  general,  we  have 


Score  =  Wd  *  D  +  Wt  *  T 


D 


D  is  the  “relative  length”  of  the  road,  that  is,  its  fraction  compared  to  the  total  distance  that  can 
be  covered  on  the  map.  To  obtain  D,  we  divide  the  length  of  the  road  (or  road  section)  by  the 
sum  of  the  lengths  of  all  roads  in  TerrainMap. 


D  =  (length  of  the  road  or  road  section)  /  (sum  of  the  lenghts  of  all  roads  in  Terrain  Map) 


T 


T  represents  the  probability  that  the  actor  will  be  captured  in  that  road.  It  depends  on  the  number 
of  threats  located  on  that  road  and  the  capture  probability  for  each  threat. 


Thus,  we  have  T  =  T1  *  T2  *  ...  *  Tn,  where  n  is  the  number  of  threats  on  the  road. 
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Tj  (i  =  1,  2,  n)  is  a  function  of  the  threat  defeatability  (Defeat;)  and  the  threat  bribability 
(Bribed.  Defeatability  is  the  probability  that  the  actor  is  able  to  defeat  the  threat  in  a  fight. 
Bribability  is  the  probability  that  the  threat  will  accept  a  bribe  from  the  actor.  To  compute  Si,  we 
use: 


T;  =  (1  -  Bribe;)  *  ( 1  -  Defeat;) 


In  other  words,  the  actor  will  only  be  captured  if  the  threat  is  not  likely  to  accept  a  bribe  and  is 
not  likely  to  be  defeated  in  a  fight  with  the  actor. 


Wd  and  Wt 


Wd  and  Wt  are  the  weights  given  to  how  important  are  the  distance  compared  to  threat  level.  In 
general,  Wt  is  substantially  larger  than  Wd  (i.e.  threat  level  is  much  more  important  than  the 
distance).  In  our  simulations,  we  set  Wd  and  Wt  to  fixed  values,  such  that  Wd  +  Wt  =  1  (in  the 
case,  Wt  =  0.9  and  Wd  =  0.1),  meaning  that  threat  level  is  9  times  more  important  to  score  a  road 
than  the  distance. 


Suggestions  for  improvement 


A  more  complex  implementation  of  the  scoring  function  would  take  advantage  of  the  decay  rate 
and  estimation  range  of  the  location  of  the  threat.  Currently,  we  score  a  road  according  to 
whether  there  is  a  threat  located  on  it.  However,  using  the  estimation  range,  we  can  say  that  the 
threat  is  somewhere  within  the  threat  position  +/-  estimation  range.  In  addition,  we  can  make  the 
estimation  range  increase  according  to  a  certain  decay  rate  as  time  goes  by  and  the  actor  did  not 
receive  updates  for  the  threat  position. 


85 


In  this  case,  as  the  estimation  range  increase,  the  threat  will  cover  more  roads,  but  its  threat  level 
on  each  road  decreases. 


Thus  we  suggest  the  following  algorithm  to  compute  the  new  threat  level  of  the  road  (New_Ti). 


For  all  threats  in  Threat  Map,  compute  the  minimum  distance  to  the  road  (minimum  distance 
means  the  distance  from  the  threat  to  the  closest  vertex  of  the  road  or  road  section).  Call  this 
distance  Mdi. 


Thus,  we  have  that,  for  that  road,  New_Tj  =  T;  /  Md;. 


Threshold  changes 


When  Route  Planner  of  the  key  figure  finds  not  acceptable  routes,  that  is,  there  are  no  routes 
where  the  score  is  under  Threat  Threshold,  the  key  figure  runs  to  the  closest  safe  house.  Once  in 
the  safe  house,  the  General  Manager  initiates  a  process  of  looking  at  the  past  history  of  threat 
levels  and  change  its  threat  tolerance  depending  upon  this  tendency. 


For  the  current  implementation,  we  use  the  following  algorithm. 


We  select  the  last  three  update  cycles  while  the  key  figure  was  in  the  safe  house.  An  update 
cycle  is  a  cycle  where  sensors  capture  new  data,  the  threat  analyzer  maps  the  threat,  and  the 
route  planner  compute  new  safest  path  given  the  new  threat  map. 
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In  each  of  these  three  cycles,  we  measure  the  best  scores  of  the  unaccepted  routes.  Let’s  call 
them  si,  s2,  and  s3,  where  s3  is  the  latest  score. 


We  specify  the  following  algorithm:  if  the  average  between  s2  and  s3  is  higher  than  the  average 
between  si  and  s2,  then  the  tendency  is  that  the  threat  level  is  increasing,  so  the  General  Planner 
raises  the  threshold.  However,  if  first  average  is  lower  than  the  second,  the  General  Planner  does 
nothing  and  wait  until  the  threat  level  lowers  to  a  level  below  its  threshold. 


Suggestions  for  improvement 


A  suggestion  for  improvement  is  to  assess  the  threat  level  tendency  by  using  more  cycles  (i.e. 
more  than  3  cycles).  In  this  case,  instead  of  comparing  averages,  we  do  a  linear  regression  and 
try  to  compute  a  line  that  best  fit  these  points.  If  the  slope  of  this  line  is  positive,  it  means  that 
the  tendency  is  to  increase  the  threat  level,  so  the  General  Planner  increases  the  threat  tolerance. 
Otherwise,  if  the  slope  is  negative,  the  General  Planner  waits  for  the  threat  level  to  decrease 
below  the  current  threshold  level. 
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Experiment  Design 


Independent  Variables 

1)  Number  of  actors 

Vary  Num_Actors 

2)  Distribution  of  categories  of  good  guys 

Given  a  number  of  actors,  specify  how  many  coalitions,  polices,  or  border  guards  and 
their  sizes  (large,  medium  or  small) 

3)  Key  Figure’s  Policy  for  Threat  Tolerance 

Vary  Threat  Threshold 

Vary  Num_Cycles 

Vary  Threshold  Change  Rate 

4)  Key  Figure’s  final  destination 

Change  Terrain_Map  (and,  thus,  Waypoints_List)  and/or 
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Select  another  waypoint  as  final  destination 


5)  Number  and  location  of  Safe  Houses 


Change  Terrain  Map  and/or 
Change  Safe  Houses  Lists 
Select  other  waypoints  as  safe  houses 


6)  Sensor  Degeneration  Rates 


Change  RangelOO,  Range_50,  and  Range_25  for  each  actor 


7)  Location  Estimation 


Change  Decay  Rates  for  each  good  guy 


8)  Probability  of  phone  call  with  opponent  position 


Change  Phone  Call  Probability  for  each  actor 
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ACTOR  A1 :  KEY  FIGURE 


Practice  Al:  Key  Figure  Route  Planner 

Information  environment 

II  Simulation  Environment 

Integer  CurrentTime  =  0; 
with  0 

Integer  EndTime  =  2,000; 

Boolean  EndSimulation; 
simulation 

End  Simulation.setValue  (false) 

//  Actor 

String  Actor_Id  =  “key  figure”; 

String  Actor_Type  =  “key  figure”; 

//  Shared  variables 

String  Final  Destination  =  “final  destination”; 

Vector  Next_Destination  =  (roadl,  0); 

Vector  Current  Position  =  Next  Destination; 


//  Track  the  current  time  tick  of  the  simulation,  init 


//  Total  number  of  time  ticks,  init  with  2000 

//  Route  Planner  uses  to  notify  end  of 


//  Init  with  false 
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Vector  CurrentRoute  =  (roadl,  “forward”); 

Real  Speed  =  0; 

Vector  Threat  Map; 

Real  ThreatThreshold  =  0.25; 

Real  Best  Score  Cycle  =  Threat  Threshold; 

//  Flags 

Boolean  Threat_Map_Flag;  //  flag  if  Threat_Map  is  updated 

Threat_Map_Flag. setV alue  (false); 

Boolean  SafeHouseMode;  //  flag  if  Route  Planner  returned  route  to  safe  house 

Safe_House_Mode.setValue  (false); 

Boolean  Cycle  Flag;  //  flag  if  Route  Planner  ran  a  cycle  of  threat  data  update 

Cycle_Flag.setValue  (false); 

Boolean  In  Safe  House;  //  flag  if  Current  Position  is  a  safe  house 

In  Safe  House.setValue  (false); 

Boolean  At_Destination;  //  flag  if  arrived  at  Next_Destination 

At_Destination.setValue  (true); 

Boolean  Target  Captured;  //  flag  if  actor  has  been  captured 

T  arget_C  aptured .  setV  alue  (false) ; 

Boolean  Go_Flag;  //  flag  Motion  Manager  to  move 

Go_Flag.setValue  (false); 
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Boolean  TargetEscaped; 


//  flag  if  arrived  at  final  destination 


Target_Escaped.setValue  (false); 

//  On-Off  Flags  for  the  practices,  initiate  all  with  true 

Boolean  Motion  Manager  On;  Motion  Manager  On.setValue  (true); 

Boolean  Gen  Planner  On;  Gen  Planner  On.setValue  (true); 

Boolean  Threat  Analyzer  On;  Threat  Analyzer  On.setValue  (true); 

Boolean  Threat  Sensor  On;  Threat  Sensor  On.setValue  (true); 

Booleant  Phone  Caller  On;  Phone  Caller  On.setValue  (true); 

//  Set  types 

set  RoadT  =  {roadl,  road2,  road3,  road4,  road5,  road6,  road7,  road8,  road9,  roadlO,  roadl  1,  road 
12,  roadl3,  roadl4,  rla,  rib,  r2a,  r2b} 

set  ThreatT  =  {not_threat,  threatl,  threat2,  threat3,  threat4} 


//  Numeric  Constants 
Real  Regular  Speed  =36; 
Real  Fast  Speed  =  60; 
Real  Wd  =  0.1; 

Real  Wt  =  0.9; 


//  see  speed  table 

//  see  speed  table 

//  weight  of  the  distance  factor  for  scoring 
//  weight  of  the  threat  level  factor  for  scoring 


//  Vector  Constants:  see  Appendix  on  how  to  initialize  these  tables 
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Vector  Terrain  Map; 


Vector  Aug_Terrain_Map; 
Vector  Waypoints_List; 
Vector  Safe_Houses_Lists; 
Vector  ThreatRiskTable; 


//  Constants  representing  indices:  Terrain_Map,  Aug_Terrain_Map,  positions,  Route 

Integer  road  id  =  0;  Integer  start  waypoint  =  1;  Integer  end  waypoint  =  2;  Integer  roadlength  = 
3;  Integer  road  cost  =  3;  Integer  edge  direction  =  4;  Integer  road_position  =  1;  Integer 
road  direction  =  1 


//  Constants  representing  indices:  ThreatMap,  Threat  Sensor  Map,  Threat  Risk  Table, 
GroundT  ruthT  able 

Integer  threat  id  =  0;  Integer  threat_position  =  1;  Integer  threat  type  =  2;  Integer  threat  size  =  3; 

Integer  position_range  =  4;  Integer  t_type  =  0;  Integer  t_size  =  1;  Integer  defeat  =  2;  Integer 
bribe  =  3; 

Integer  actor  name  =  1;  Integer  actor_position  =  2; 

//  Local 

Vector  ProposedRoute; 
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Monitors 


monitor  MonitorRouting  (Threat  Map  Flag,  Best_Score_Cycle,  InSafeHouse) 

{ 

If  (Threat  Map  Flag  ==  true)  { 

propose  Route.Main  ();  II  find  best 

route  to  final  destination 


If  (BestScoreCycle  <=  Threat  Threshold)  {  //  if  route  acceptable, 

go  to  final  destination 

go_  To  Final  Destination.Main  () ; 

Safe_House_Mode.setValue  (false); 

GoFlag.setValue  (true); 

} 


house 


Else  If  (Best_Score_Cycle  >  Threat_Threshold)  //  if  not  acceptable,  go  to  safe 


if  (In  Safe  House  ==  false)  { 

go_To_Best_Safehouse.Main  (); 
Safe_House_Mode.setValue  (true); 
Go  Flag.setValue  (true); 

} 
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Else 


Go  Flag.setValue  (false); 

Threat_Map_Flag  =  false;  //  reset  flag  for  new  updates  on  threat  locations 
(Threat  Analyzer) 

Cycle_Flag  =  true;  //  reset  flag  for  new  update  cycle  (General 

Planner) 

} 

} 

monitor  MonitorSimulationEnd  (CurrentTime,  Target  Captured,  CurrentPosition) 

{ 

Target  Escaped.setValue  ( is_Final_Destination  (Current  Position)); 

if  ((Current_Time  ==  End_Time)  ||  (Target_Captured)  ||  (Target_Escaped))  { 
EndSimulation.setValue  (true); 

Motion_Manager_On.setValue  (false); 

Gen  Planner  On.setValue  (false); 

Threat  Analyzer  On.setValue  (false); 

Threat  Sensor  On.setValue  (false); 

Phone  Caller  On. setV alue  (false); 

} 
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} 


Activity  Generator 


activityGen  proposeRoute 

{ 


void  InitializeQ  {} 


void  Main() 

{ 


ProposedRoute  =  getSafestRoute  (Current  Position,  Final  Destination); 
Best  Score  Cycle  =  route  Score  (Route); 


} 


void  Resume()  {} 
void  Pause()  {} 
void  KillQ  {} 


} 


activityGen  go_To_Final_Destination 

{ 


void  InitializeQ  {} 
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void  Main() 


{ 

CurrentRoute  =  ProposedRoute;  //  Commit  to  proposed  route 

Next_Destination  =  get_Next_Destination_Coord  (Current_Route); 

Speed  =  Regular_Speed; 

} 

void  Resume()  {} 
voidPause()  {} 
void  Kill()  {} 

} 

activityGen  go_To_Best_Safehouse 

{ 

void  Initialize()  {} 

void  Main() 

{ 

Current  Route  =  route_To_Safe_House  (); 

Next_Destination  =  get_Next_Destination_Coord  (Current_Route); 

Speed  =  Fast_Speed; 

} 
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void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 


98 


Practice  A2:  General  Planner 


Information  environment 

II  Shared  variables 
Real  ThreatThreshold; 

Real  Best  Score  Cycle; 

//  Flags 

Boolean  Cycle  Flag; 

Boolean  InSafeHouse; 

//  On-Off  Flags 
Boolean  Gen  Planner  On; 

//  Local  variables 
Vector  BestScoreHistory; 

Integer  Safe_House_Cycles  =  0;  //  init  =  0 

//  Local  numeric  Constants 

Integer  NumCycles;  //  Init  =  3,  see  variables 
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Real  ThresholdChangeRate; 


//  Init  =1.1,  see  variables 


Monitors 


monitor  Monitor  Cycle  (Cycle  Flag,  InSafeHouse,  Safe  House  Cycles) 

{ 


if  (Cycle_Flag)  { 


track  Score  History.Main  (); 


if  (In  Safe  House)  { 

Safe_House_Cycles++; 

adjust_Threshold.Main  (); 


} 

else 


Safe_House_Cycles  =  0; 


Cycle_Flag  =  false;  //  reset  flag  for  next  cycle 


} 


} 


100 


monitor  MonitorOnOff  (GenPlannerOn) 

{ 

if  (Gen  Planner  On  ==  false)  { 

trackScoreHistory. Pause  (); 
adjust_Threshold.Pause  ()\ 

} 

} 

Activity  Generator 

activityGen  track_Score_History 

{ 

void  Initialize()  {} 

void  Main() 

{ 

//  Check  if  Best_Score_History  reached  NumCycles.  If  yes,  remove  earlist  element  (at  0); 
if  (Best_Score_History.size()  >  NumCycles)  Best_Score_History.removeElementAt  (0); 

//  insert  most  recent  score  at  the  end  of  the  collection 
B est  Sc ore  History . addElement  (B est_S core) ; 

} 
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void  ResumeQ  {} 


void  Pause()  {} 
void  Kill()  {} 

} 

activityGen  adjust_Threshold 

{ 

void  Initialize()  {} 

void  Main() 

{ 

If  (Safe_House_Cycles  >  NumCycles)  { 

Integer  Lastlndex  =  Best_Score_History.size()  -  1; 

Real  Last  Point  =  BestScoreHistory.elementAt  (Last  lndex); 

Real  Point  _2  =  Best  Score  History.elementAt  (Last  lndex  -  1); 

Real  Point  _3  =  Best  Score  History.elementAt  (Last  lndex  -  2); 

Real  Avgl  =  (Last_Point  +  Point_2)  /  2; 

Real  Avg2  =  (Point_2  +  Point_3)  /  2; 

if  (Avg2  >=  Avgl)  ThreatThreshold  =  ThresholdlncreaseRange  * 
ThreatThreshold; 
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} 


void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 
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Practice  A3:  Key  Figure  Motion  Manager 


Information  environment 

II  Actor 

String  Actor_Id  //  “key  figure” 

//  Shared  variables 
Vector  Next_Destination; 

Vector  Current  Position; 

Vector  CurrentRoute; 

Vector  GroundTruthTable;  //  init  from  Appendix 
Real  Speed; 

//  Flags 

Boolean  InSafeHouse; 

Boolean  AtDestination; 

Boolean  Go  Flag; 

//  On-Off  Flags 

Boolean  Motion  Manager  On; 


104 


//  Sets 


set  RoadT  =  {roadl,  road2,  road3,  road4,  road5,  road6,  road7,  road8,  road9,  roadlO,  roadl  1,  road 
12,  roadl3,  roadl4,  rla,  rib,  r2a,  r2b} 

set  ThreatT  =  {not_threat,  threatl,  threat2,  threat3,  threat4} 

//  Numeric  Constants 
Real  Regular  Speed; 

Real  Fast  Speed; 

//  Vector  Constants:  see  Appendix 
Vector  Terrain  Map; 

Vector  Aug_Terrain_Map; 

Vector  Waypoints_List; 

Vector  Safe_Houses_Lists; 


//  Constants  representing  indices:  Terrain_Map,  Aug_Terrain_Map,  positions,  Route 

Integer  road  id  =  0;  Integer  start  waypoint  =  1;  Integer  end  waypoint  =  2;  Integer  road  length  = 
3;  Integer  road  cost  =  3;  Integer  edge  direction  =  4;  Integer  road_position  =  1;  Integer 
road  direction  =  1 


//  Constants  representing  indices:  Threat_Map,  Threat_Sensor_Map,  Threat_Risk_Table, 
Ground  Truth  Table 
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Integer  threat  id  =  0;  Integer  threat_position  =  1;  Integer  threat  type  =  2;  Integer  threatsize  =  3; 

Integer  position_range  =  4;  Integer  t_type  =  0;  Integer  t_size  =  1;  Integer  defeat  =  2;  Integer 
bribe  =  3; 

Integer  actorname  =  1;  Integer  actor_position  =  2; 

//  Local 

Boolean  No_Motion;  No_Motion.setValue  (false);  //  flag  if  Motion  Manger  is  paused 

Monitors 

monitor  MonitorManagerOnOff  (MotionManagerOn) 

{ 

if  (Motion_Manager_On) 

inoveKeyFigure.Main  (); 

} 

monitor  Monitor_Motion  (Go_Flag,  No_Motion) 

{ 

if  (GoFlag  ==  false) 

move  Key  Figure.Pause  (); 
else  if  (No_Motion)  { 

move  Key  Figure.Resume  ()\ 
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} 


} 


Activity  Generator 


activityGen  move_Key_Figure 

{ 


void  InitializeQ  {} 


void  Main() 

{ 

Real  Positionlnc  =  Speed  /  60;  //  calculate  position  increment  in  one  time 

tick  given  speed 


Real  DestDistance  =  routeDistance  (CurrentPosition,  NextDestination, 
CurrentRoute); 


//  if  destination  is  within  Position  lnc,  mark  that  reached  destination  and  check  if  in  safe 

house 


If  (Dest  Distance  <=  Position  lnc)  { 

CurrentPosition  =  NextDestination; 

At_Destination.setValue  (true); 

if  (is_Safe_House_Position  (Current  Position))  In  Safe  House.setValue  (true); 
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} 


Else  CurrentPosition  =  find_Next_Position  (DestDistance,  CurrentPosition, 
CurrentRoute); 


update_Truth_Table_Position  (Actor  id,  Current  Position); 


} 


void  Resume() 

{ 

No_Motion.setValue  (false); 

} 


void  Pause() 

{ 

No_Motion.setValue  (true); 

} 


void  KillQ  {} 


} 
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Practice  A4:  Threat  Analyzer 


Information  environment 

II  Shared  variables 

Vector  Threat_Sensor_Data;  //  initially  empty 

Vector  Threat_Map;  //  see  Appendix  for  initialization 

//  Flags 

Boolean  Threat  Map  Flag; 

//  On-Off  Flags 

Boolean  Threat  Analyzer  On; 

//  Sets 

set  RoadT  =  {roadl,  road2,  road3,  road4,  road5,  road6,  road7,  road8,  road9,  roadlO,  roadl  1,  road 
12,  roadl3,  roadl4,  rla,  rib,  r2a,  r2b} 

set  ThreatT  =  {not_threat,  threatl,  threat2,  threat3,  threat4} 

//  Constants  representing  indices:  Terrain_Map,  Aug_Terrain_Map,  positions,  Route 
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Integer  road  id  =  0;  Integer  start  waypoint  =  1;  Integer  end  waypoint  =  2;  Integer  roadlength  = 
3;  Integer  road  cost  =  3;  Integer  edge  direction  =  4;  Integer  road_position  =  1;  Integer 
road  direction  =  1 


//  Constants  representing  indices:  Threat  Map,  Threat  Sensor  Map,  Threat  Risk  Table, 
GroundT  ruthT  able 

Integer  threatid  =  0;  Integer  threat_position  =  1;  Integer  threat  type  =  2;  Integer  threatsize  =  3; 

Integer  position_range  =  4;  Integer  t_type  =  0;  Integer  t_size  =  1;  Integer  defeat  =  2;  Integer 
bribe  =  3; 

Integer  actor  name  =  1;  Integer  actor_position  =  2; 


Monitors 


monitor  Monitor  Threat  Sensor  Data  (Threat  Sensor  Data) 

{ 

If  (Threat  Sensor  Data.size  ()  >  0) 
process  Messages.Main  (); 

} 

monitor  MonitorAnalyzerOnOff  (ThreatAnalyzerOn) 

{ 

If  (Threat  Analyzer  On  ==  false) 
process  Messages.Pause  ( ); 
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} 


Activity  Generator 

activityGen  process  Messages 

{ 

void  Initialize()  {} 

void  Main() 

{ 

Vector  Message; 

//  Read  messages  and  update  Threat_Map 
Integer  i  =  0; 

while  (i  <  Threat_Sensor_Data.size())  { 

Message  =  Threat_Sensor_Data.elementAt  (i); 
process  A  Message  (Message,  Threat_Map); 

i++; 

} 

//  clear  message  table 
i  =  Threat  Sensor  Data.size  ()  —  1; 
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while  (i  >=  0)  { 


Threat  s  ensor  Data .  remo veElement At  (i) ; 


} 

Threat_Map_Flag.setValue(true); 


} 


void  Resume()  {} 
void  Pause()  {} 
void  KillQ  {} 


} 
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Practice  A5:  Threat  Sensor 


Information  environment 

II  Shared  variables 
Vector  CurrentPosition; 

Vector  Threat  Sensor  Data; 

Vector  Ground  Truth  Table; 

//  On-Off  Flags 
SensorOn; 

//  Sets 

set  RoadT  =  {roadl,  road2,  road3,  road4,  road5,  road6,  road7,  road8,  road9,  roadlO,  roadl  1,  road 
12,  roadl3,  roadl4,  rla,  rib,  r2a,  r2b} 

set  ThreatT  =  {not_threat,  threatl,  threat2,  threat3,  threat4} 

//  Vector  Constants:  see  Appendix 
Vector  Terrain  Map; 

Vector  Aug_Terrain_Map; 

Vector  Waypoints_List; 

Vector  Safe  Houses  Lists; 
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Vector  ThreatRiskTable; 


//  Constants  representing  indices:  Terrain_Map,  Aug_Terrain_Map,  positions,  Route 

Integer  road  id  =  0;  Integer  start  waypoint  =  1;  Integer  end  waypoint  =  2;  Integer  roadlength  = 
3;  Integer  road  cost  =  3;  Integer  edge  direction  =  4;  Integer  road_position  =  1;  Integer 
road  direction  =  1 


//  Constants  representing  indices:  Threat_Map,  Threat_Sensor_Map,  Threat_Risk_Table, 
GroundT  ruthT  able 

Integer  threat  id  =  0;  Integer  threat_position  =  1;  Integer  threat  type  =  2;  Integer  threat  size  =  3; 

Integer  position_range  =  4;  Integer  t_type  =  0;  Integer  t_size  =  1;  Integer  defeat  =  2;  Integer 
bribe  =  3; 

Integer  actorname  =  1;  Integer  actor_position  =  2; 


Monitors 


monitor  Monitor  Sensor  (Sensor  On) 

{ 

if  (Sensor  On) 

scan  Threats.Main  (); 

else 


} 


scan  Threats.Pause  (): 
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Activity  Generator 


activityGen  scan_Threats 

{ 

void  Initialize()  {} 

void  Main() 

{ 

Vector  GTElem; 

Vector  Position; 

Real  D; 

Boolean  Detected; 

Integer  i  =  1;  //  Start  with  second  element  of  GroundTruthTable  ->  the  first  is 

key  figure 

While  (i  <  Ground_Truth_Table.size())  { 

GTElem  =  GroundTruthTable.elementAt(i); 

Position  =  GTElem.  element  At  (actor_position); 

D  =  distance  (Current  Position,  Position); 

if  (D  <  range_100)  Detected  =  “true”; 

else  if  ((D  >=  range_100)  and  (D  <  range_50))  Detected  =  randomBinary  (0.5); 
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else  if  ((D  >=  range  50)  and  (D  <  range  25))  Detected  =  random  Binary  (0.25); 
else  Detected  =  “false”; 

if  (Detected  ==  “true”)  sendMessage  (GT_Elem.elementAt(threat_id),  Position); 

i++; 

} 

} 

void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 
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Practice  A6:  Threat  Phone  Caller 


Information  environment 

II  Shared  variables 
Vector  Threat  Sensor  Data; 

Vector  Ground  Truth  Table; 

Vector  CurrentPosition; 

//  On-Off  Flags 
Boolean  PhoneCallerOn; 

//  Local  Numerical  constants 

Real  Phone_Call_Probability  =  0.4;  //  see  table 

Monitors 

monitor  Monitor  Phone  Caller  (Bool  Phone  Caller  On) 

{ 

if  (Phone  Caller  On) 

scan  Threats.Main  ()\ 
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else 


scan  Threats.Pause  (); 

} 

Activity  Generator 

activityGen  scan  Threats 

{ 

void  Initialize()  {} 

void  Main() 

{ 

Vector  GTElem; 

Vector  Position; 

Real  D; 

Boolean  Detected; 

Integer  i  =  1;  //  Start  with  second  element  of  Ground  Truth  Table  ->  the  first  is 

key  figure 

while  (i  <  Ground_Truth_Table.size())  { 

GTElem  =  GroundTruthTable.elementAt(i); 

Position  =  GTElem.elementAt  (actor_position); 
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Detected  =  ran domBin ary  (Phonc  Call  Probability); 

if  (Detected  ==  “true”)  sendMessage  (GT_Elem.elementAt  (threat_id), 

position); 

i++; 


} 


} 


void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 
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ACTOR  B:  GOOD  GUYS 

Practice  Bl:  Good  Guys  Route  Planner 

Information  environment 

II  Simulation  Environment 

Integer  CurrentTime  =  0; 
with  0 

Integer  EndTime  =  2,000; 

Boolean  EndSimulation; 
simulation 

End  Simulation.setValue  (false) 

//  Actor 

String  Actor  id  =  “coalition  1”; 

1”,  etc.  See  simulation  settings 

String  Actor_Type  =  “coalition”; 

String  Actor_Size  =  “large”; 

//  Shared  variables 

Vector  Next_Destination  =  (road5,  1);  //  initialize  with  a  random  point.  See 

appendix 
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//  or  “police  1”,  “police  2”,  “border  guard 

//  or  “police”,  “border  guard” 

//  or  “med”,  “small” 


//  Track  the  current  time  tick  of  the  simulation,  init 


//  Total  number  of  time  ticks,  init  with  2000 

//  Route  Planner  uses  to  notify  end  of 


//  Init  with  false 


Vector  CurrentPosition  =  Next  Destination; 

Vector  Current_Route  =  (road5,  “forward”);  I  I  Make  sure  the  road  is  the  same  from 

Next_Destination 

Real  Speed  =  0; 

Vector  Ground  Truth  Table; 

Vector  TargetPositionEstimate  =  Next  Destination; 
start  with  current  position 

Real  Target  Position  Range  =  50; 
location,  indicate  location  accuracy 

//  Flags 

Boolean  At_Destination;  //  flag  if  arrived  at  Next_Destination 

At_Destination.setValue  (true); 

Boolean  Target  Captured;  //  flag  if  actor  has  been  captured 

T arget  C aptured . setV alue  (false) ; 

Boolean  Go_Flag;  //  flag  Motion  Manager  to  move 

Go_Flag.setValue  (false); 

Boolean  Target_Escaped;  //  flag  if  arrived  at  final  destination 

Target_Escaped.setValue  (false); 

Boolean  New_Update;  //  flag  if  there  is  some  update  from  either  sensor  or 

phone  call 

New_Update.setValue  (false); 


//  current  estimate  for  target  location, 


//  range  surrounding  target 
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//  On-Off  Flags  for  the  practices,  initiate  all  with  true 

Boolean  Motion  Manager  On;  Motion  Manager  On.setValue  (true); 

Boolean  SensorReaderOn;  SensorReaderOn.setValue  (true); 

Boolean  Phone  Answerer  On;  Phone  Answerer  On.setValue  (true); 

Boolean  Pos  Conflict  Res  On;  PosConfhctResOn.setValue  (true); 

Boolean  Target  Sensor  On; 

Booleant  Phone  Caller  On;  Phone  Caller  On.setValue  (true); 

//  Set  types 

set  RoadT  =  {roadl,  road2,  road3,  road4,  road5,  road6,  road7,  road8,  road9,  roadlO,  roadl  1,  road 
12,  roadl3,  roadl4,  rla,  rib,  r2a,  r2b} 

set  ThreatT  =  {not_threat,  threatl,  threat2,  threat3,  threat4} 

//  Numeric  Constants 

Real  Regular_Speed  =  30;  //  see  speed  table 

Real  Fast_Speed  =  72;  //  see  speed  table 

Integer  Decay_Rate  =  2;  //  increase  in  the  location  range  per  time  tick  when  actor 

receives  no  location  updates 

Real  Capture  Range  =  1 ;  //  good  guy  captures  target  if  their  distance  <  Capture  Range 

//  Vector  Constants:  see  Appendix  on  how  to  initialize  these  tables 
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Vector  Terrain  Map; 


Vector  Aug_Terrain_Map; 
Vector  Waypoints_List; 
Vector  Safe_Houses_Lists; 
Vector  ThreatRiskTable; 


//  Constants  representing  indices:  Terrain_Map,  Aug_Terrain_Map,  positions,  Route 

Integer  road  id  =  0;  Integer  start  waypoint  =  1;  Integer  end  waypoint  =  2;  Integer  roadlength  = 
3;  Integer  road  cost  =  3;  Integer  edge  direction  =  4;  Integer  road_position  =  1;  Integer 
road  direction  =  1 


//  Constants  representing  indices:  ThreatMap,  Threat  Sensor  Map,  Threat  Risk  Table, 
GroundT  ruthT  able 

Integer  threat  id  =  0;  Integer  threat_position  =  1;  Integer  threat  type  =  2;  Integer  threat  size  =  3; 

Integer  position_range  =  4;  Integer  t_type  =  0;  Integer  t_size  =  1;  Integer  defeat  =  2;  Integer 
bribe  =  3; 

Integer  actor  name  =  1;  Integer  actor_position  =  2; 

//  Local 

Boolean  Target  Located; 
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Monitors 


monitor  Monitor_Routing  (New_Update,  At_Destination) 

{ 


if  (New_Update) 

go  To  Target. Main  O', 


If  (At  Destination)  { 

go_  To  Random  Destination.Main  () ; 


} 


monitor  Monitor  Travel  Mode  (TargetPositionRange) 


TargetLocated  =  is  Position  Accurate  (Target  Position  Range); 


if  (Target  Located) 

pursue.Main  ()\ 


else 


patrol.Main  (); 


} 


monitor  Monitor  Simulation  End  (Current  Time,  Target  Captured,  Current  Position) 
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Target  Escaped.setValue  (is_ Target  Captured  (CurrentPosition)); 

if  ((Current_Time  ==  End_Time)  ||  (Target_Captured)  ||  (Target_Escaped))  { 
End  Simulation.setValue  (true); 

Motion_Manager_On.setValue  (false); 

Sensor  Reader  On.setValue  (false); 

Phone_Answerer_On.  setV alue  (false); 

PosConflictResOn.  setValue  (false); 

Target  Sensor  On.setValue  (false); 

PhoneCallerOn.  setV  alue  (false); 

} 

} 

Activity  Generator 

activityGen  go_To_Target 

{ 

void  Initialize()  {} 
void  Main() 

{ 

Next_Destination  =  Target_Position_Estimate; 
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CurrentRoute  =  getShortestRoute  (CurrentPosition,  Next  Destination); 

} 

void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 

activityGen  go_To_Random_Destination 

{ 

void  Initialize()  {} 

void  Main() 

{ 

RoadT  CurRoad  =  CurrentPosition.elementAt  (roadid); 

Real  Cur  Road  Pos  =  Current  Position.elementAt  (road_position); 

Real  Road  Len  =  get  Road  Length  (Cur  Road); 

Vector  Road  List  =  get  Near  Roads  (Cur  Road); 

Integer  N  =  Road_List.size(); 

RoadT  Next_Road  =  Road_List.elementAt  ( rand  lnt  (0,  N  -  1)); 
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Real  Next_Road_Pos  =  randlnt  (0,  getLengthRoad  (Next_Road)); 

Next_Destination.setElementAt  (road_id,  Next_Road); 
Next_Destination.setElementAt  (road_position,  Next_Road_Position); 

Current  Route  =  get  Shortest  Route  (Current  Position,  Next  Destination); 
At_Destination.setValue  (false); 


void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 

activityGen  pursuit 

{ 

void  Initialize()  {} 
void  Main() 


{ 

Speed  =  Fast_Speed; 

} 


void  Resume()  {} 


127 


void  PauseQ  {} 


void  KillQ  {} 


} 

activityGen  patrol 

{ 


void  Initialize()  {} 


void  Main() 

{ 


Speed  =  RegularSpeed; 


} 


void  Resume()  {} 
void  Pause()  {} 
void  KillQ  {} 


} 
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Practice  B2:  Good  Guys  Motion  Manager 


Information  environment 

II  Actor 

String  Actor_id; 

//  Shared  variables 
Vector  Next_Destination; 
Vector  Current  Position; 
Vector  CurrentRoute; 

Real  Speed; 

Vector  GroundTruthTable; 

//  Flags 

Boolean  Target  Captured; 
Boolean  AtDestination; 

//  On-Off  Flags 

Boolean  Motion  Manager  On; 


//  “coalition  1” 


//  init  with  false 
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//  Numeric  Constants 


Real  RegularSpeed; 

Real  Fast  Speed; 

Real  Capture  Range; 

//  Sets 

set  RoadT  =  {roadl,  road2,  road3,  road4,  road5,  road6,  road7,  road8,  road9,  roadlO,  roadl  1,  road 
12,  roadl3,  roadl4,  rla,  rib,  r2a,  r2b} 

set  ThreatT  =  {not_threat,  threatl,  threat2,  threat3,  threat4} 

//  Vector  Constants:  see  Appendix 
Vector  Terrain  Map; 

Vector  Aug_Terrain_Map; 

Vector  Waypoints_List; 

Vector  Safe  Houses  Lists; 

Vector  Threat  Risk  Table; 


//  Constants  representing  indices:  Terrain_Map,  Aug_Terrain_Map,  positions,  Route 

Integer  road  id  =  0;  Integer  start  waypoint  =  1;  Integer  end  waypoint  =  2;  Integer  road  length  = 
3;  Integer  road  cost  =  3;  Integer  edge  direction  =  4;  Integer  road_position  =  1;  Integer 
road  direction  =  1 
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//  Constants  representing  indices:  Threat_Map,  Threat_Sensor_Map,  Threat_Risk_Table, 
GroundT  ruthT  able 

Integer  threatid  =  0;  Integer  threat_position  =  1;  Integer  threat  type  =  2;  Integer  threatsize  =  3; 

Integer  position_range  =  4;  Integer  t_type  =  0;  Integer  t_size  =  1;  Integer  defeat  =  2;  Integer 
bribe  =  3; 

Integer  actorname  =  1 ;  Integer  actor_position  =  2; 

Monitors 

Monitor_Motion_Manager_Status 

{ 

if  (Motion_Manager_On) 
moveGG.Main  (); 

else 

move  GG.Pause  (); 

} 

Activity  Generator 

activityGen  move  GG 

{ 

void  InitializeQ  {} 
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void  Main() 


{ 


Real  Positionlnc  =  Speed  /  60; 
tick  given  speed 


//  calculate  position  increment  in  one  time 


Real  DestDistance  =  routeDistance  (CurrentPosition,  NextDestination, 
CurrentRoute); 


if  (Dest  Distance  <=  Position  lnc)  { 

CurrentPosition  =  NextDestination; 

At_Destination.setValue  (true); 

} 

Else  CurrentPosition  =  find _N ext Position  (DestDistance,  CurrentPosition, 
CurrentRoute); 

update  Truth  Table  Position  (Actor  id,  Current  Position); 

} 


void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 
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Practice  B3:  Target  Sensor  Reader 


Information  environment 

II  Shared  Variables 
Vector  CurrentPosition; 

Vector  TargetPositionEstimate; 

Real  DecayRate; 

Vector  Sensor_Report;  //  position  of  the  target  from  sensor 

//  Flag 

Boolean  New_Update; 

Boolean  New_Sensor_Update;  //  indicate  an  update  of  target  position  from  sensor 

New_Sensor_Update.setValue  (false); 

//  On-Off  Flag 

Boolean  Sensor  Reader  On; 

Boolean  ResolverGo; 

Boolean  Go  Sensor; 
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Monitors 


MonitorSensorReaderOn  (SensorReader  On, 

TargetPositionRange) 

{ 

decay  (Target  Position  Range); 

New_Update  =  “false”; 

If  (Sensor  Reader  On)  { 

if  (New_Sensor_Update)  { 

while  (Resolver_Go_Sensor  ==  false)  {}; 
if  (GoSensor) 

checkSensor.Main  0; 

} 

Else 

checkSensor. Pause  (); 

} 

Activity  Generator 

activityGen  check_Sensor 

{ 

void  InitializeQ  {} 


New_Sensor_Update, 


//  wait  until  go  from  resolver 
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void  Main() 


{ 

if  (Sensor_Report.size()  >  0)  { 

Target  Position  Estimate  =  removeElementAt  (Sensor  Report); 
TargetPositionRange  =  0; 

N  ew_Update .  setV  alue(true) ; 
New_Sensor_Update.setValue(false); 

} 

} 


void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 
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Practice  B4:  Target  Phone  Answerer 


Information  environment 

II  Shared  Variables 
Vector  CurrentPosition; 

Vector  TargetPositionEstimate; 

Real  DecayRate; 

Vector  PhoneReport;  //  position  of  the  target  from  phone  caller 

//  Flag 

Boolean  New_Update; 

Boolean  New  Phone  Call;  //  indicate  an  update  of  target  position  from  phone 

caller 

New_Phone_Call.setValue  (false); 

//  On-Off  Flag 

Boolean  Phone  Answerer  On; 

Boolean  ResolverGo; 

Boolean  Go  Phone; 
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Monitors 


MonitorPhoneAnswererOn  (PhoneAnswererOn,  NewPhoneCall, 

TargetPositionRange) 

{ 

New_Update  =  “false”; 

If  (Phone  Answerer  On)  { 

if  (New_Phone_Call)  { 

while  (Resolver_Go  ==  false)  {};  //  wait  until  go  from  resolver 

if  (GoPhone) 

checkPhone. Main  ()\ 

} 

} 

Else 

check  Phone.Pause  ( ); 

} 

Activity  Generator 


activityGen  check_Phone 

{ 
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void  InitializeQ  {} 


void  Main() 

{ 

if  (PhoneReport.size  ()  >  0)  { 

TargetPositionEstimate  =  removeElementAt  (PhoneReport); 
TargetPositionRange  =  0; 

NewUpdate.  set  Value  (true); 

N  ew_Phone_C  all .  setV  alue(false) ; 

} 

} 


void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 
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Practice  B5:  Position  Conflict  Resolver 


Information  environment 

II  Shared  Variables 
Vector  CurrentPosition; 

Vector  TargetPositionEstimate; 

Vector  SensorReport; 

Vector  PhoneReport; 

//  Flag 

Boolean  New_Update; 

Boolean  Resolver  Go;  //  flag  the  sensor  and  phone  answerer  to  wait  for  go 

Resolver_Go.setValue  (false); 

Boolean  Go_Sensor;  //  flag  the  sensor  reader  to  go 

Go_Sensor.setValue  (false); 

Boolean  Go  Phone;  //  flag  the  telephone  answerer  to  go 

Go  Phone.setValue  (false); 

//  On-Off  Flag 

Boolean  Pos  Conflict  Res  On; 
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Monitors 


Monitor  Conflict  (PosConflictResOn,  New  Update,  SensorReport,  PhoneReport) 

{ 

If  (Pos  Conflict  Res  On)  { 

if  ((New_Phone_Call)  &&  (New_Sensor_Update)) 

if  (Sensor  Report  !=  Phone  Report))  { 

resolve_ ConflictingPos.Main  () ; 

else  { 

Go  Sensor.setValue  (true); 

Go_  Phone. setValue  (true); 

} 

} 

Else 

resolve_ Conflicting  Pos.Pause  () ; 

Resolver  Go. setValue  (true); 

} 
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Activity  Generator 


activityGen  resolveConflictingPos 

{ 

void  Initialize()  {} 

void  Main() 

{ 

//  resolution  policy  can  be  complex 

//  simplest  solution:  always  choose  sensor  report 

Go  Sensor.setValue  (true); 

Go_  Phone. setValue  (false); 

} 

void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 
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Practice  B6:  Target  Sensor 


Information  environment 

II  Shared  variables 
Vector  SensorReport; 

Vector  Ground  Truth  Table; 

Vector  CurrentPosition; 

//  Flags 

Boolean  New_Sensor_Update; 

//  On-Off  Flags 

Boolean  Target  Sensor  On; 

//  Sets 

set  RoadT  =  {roadl,  road2,  road3,  road4,  road5,  road6,  road7,  road8,  road9,  roadlO,  roadl  1,  road 
12,  roadl3,  roadl4,  rla,  rib,  r2a,  r2b} 

set  ThreatT  =  {not_threat,  threatl,  threat2,  threat3,  threat4} 

//  Vector  Constants:  see  Appendix 
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Vector  Terrain  Map; 


Vector  Aug_Terrain_Map; 
Vector  Waypoints_List; 
Vector  Safe_Houses_Lists; 
Vector  ThreatRiskTable; 


//  Constants  representing  indices:  Terrain_Map,  Aug_Terrain_Map,  positions,  Route 

Integer  road  id  =  0;  Integer  start  waypoint  =  1;  Integer  end  waypoint  =  2;  Integer  roadlength  = 
3;  Integer  road  cost  =  3;  Integer  edge  direction  =  4;  Integer  road_position  =  1;  Integer 
road  direction  =  1 


//  Constants  representing  indices:  ThreatMap,  Threat  Sensor  Map,  Threat  Risk  Table, 
GroundT  ruthT  able 

Integer  threat  id  =  0;  Integer  threat_position  =  1;  Integer  threat  type  =  2;  Integer  threat  size  =  3; 

Integer  position_range  =  4;  Integer  t_type  =  0;  Integer  t_size  =  1;  Integer  defeat  =  2;  Integer 
bribe  =  3; 

Integer  actor  name  =  1;  Integer  actor_position  =  2; 


Monitors 


Monitor  T arget  S  ensor  On  ( T arget  S  ensor  On) 

{ 

if  (TargetSensorOn) 
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reportLocation.Main  (); 


else 


report  Location.Pause  (); 


} 


Activity  Generator 


activityGen  report_Location 

{ 


void  InitializeQ  {} 


void  Main() 

{ 


Vector  T arg  Position  =  get_  Truth_  TablePosition  (“key  figure”); 
Boolean  Detected; 

Real  D; 


if  {is_Safe_House_Position  (Targ  Position)) 
Detected  =  “false” 


else  { 


D  =  distance  (Current  Position,  Key  Figure  Position); 
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if  (D  <  range  lOO)  Detected  =  “true”; 

else  if  ((D  >=  range_100)  and  (D  <  range_50))  Detected  =  randomBinary  (0.5); 
else  if  ((D  >=  range  50)  and  (D  <  range  25))  Detected  =  random  Binary  (0.25); 
else  Detected  =  “false”; 

} 

if  (Detected)  { 

SensorReport  =  TargPosition; 

New_Sensor_Update.setValue(true); 

} 

} 


void  Resume()  {} 
void  Pause()  {} 
void  Kill()  {} 

} 
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Practice  B7:  Target  Phone  Caller 


Information  environment 

II  Shared  Variables 
Vector  CurrentPosition; 

Vector  PhoneReport; 

Vector  Ground  Truth  Table; 

//  Flags 

Boolean  NewPhoneCall; 

//  On-Off  Flags 
Boolean  PhoneCallerOn; 

//  Numerical  Constant 
Real  Phone  Call  Probability; 

Monitors 

Monitor  Phone  Caller  On  (Phone  Caller  On) 

{ 
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if  (PhoneCallerOn) 

report  Location.Main  (): 


else 


report  Location.Pause  (); 


} 

Activity  Generator 


activityGen  report_Location 

{ 


void  Initialize()  {} 


void  Main() 

{ 


Vector  T arg  Position  =  get_  Truth_  TablePosition  (“key  figure”); 
Boolean  Detected 


Detected  =  random_Binary  (Phone  Call  Prob); 
if  (Detected  ==  “true”)  { 

PhoneReport  =  TargPosition; 
New_Phone_Call.setValue  (true); 


} 


} 
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/***  PROCEDURES  key  figure  route  planner  ****/ 


//  is  Final  Destination:  check  if  Position  is  Final  Destination 

Boolean  is_Final_Destination  (Vector  Position) 

{ 

RoadT  Road  =  Position.  elementAt  (road  id); 

Real  RoadPos  =  Position. elementAt  (road_position); 
Vector  Map_Elem; 


Integer  i  =  0; 

while  (i  <  Terrain_Map.size  ())  { 

MapElem  =  TerrainMap.  elementAt  (i); 

if  (Map_Elem.  elementAt  (end_waypoint)  ==  “final  destination”)  { 

if  ((Map_Elem. elementAt  (road_id)  ==  Road)  &&  (Map_Elem. elementAt 
(roadlength)  ==  RoadPos)) 

return  true; 

} 

i++; 

} 

return  false; 

} 
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/***  getSafestRoute:  return  a  route  from  Position  to  a  waypoint  that  minimizes  threat  and 
distance  ***/ 

Vector  get  Safest  Route  (RoadT  Position,  String  Wp) 

{ 

RoadT  Road  =  Position.  elementAt(roadid); 

Real  RoadPos  =  Position,  element  At  (road_pos); 

//  get  the  vertices  (waypoints)  of  the  road 
String  S  =  startWp  (Road)); 

String  E  =  endWp  (Road); 

//  Buid  Vertices  and  insert  “start_v” 

Vector  Vertices  =  Waypoints_List.copy  (); 

Vertices. addElement  (“start_v”); 

//  Build  Edges 

Vector  Edges  =  Aug_Terrain_Map.copy  (); 

//  Update  the  cost  values  for  each  edge 
Vector  Edge_Elem; 

Real  Score; 
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Integer  i  =  0; 


while  (i  <  Edges. size())  { 

Edge_Elem  =  Edges. elementAt(i); 

Score  =  scoreRoad  (Edge_Elem.elementAt(road_id)); 
Edge_Elem.setElementAt  (road_cost,  Score); 

Edges. setElementAt  (i,  Edge_Elem); 
i++; 

} 

//  Insert  new  edges  with  new  scores 

Score  =  scoreRoadSection  (Road,  RoadPos,  1); 

Edges. addElement  {newEdge  (rla,  S,  “start_v”,  Score,  “forward”)); 
Edges. addElement  ( newEdge  (rla,  ”start_v”,  S,  Score,  “backward”)); 
Score  =  score  Road  Section  (Road,  Road  Pos,  2); 

Edges. addElement  ( new  Edge  (rib,  ”start_v”,  E,  Score,  “forward”)); 
Edges. addElement  ( new  Edge  (rib,  E,  “start_v”,  Score,  “backward”); 

Vector  Route; 

Route  =  shortestRouteDijisktra  (“start_v”,  Wp,  Vertices,  Edges)); 

//  Replace  rla  and  r2a  for  Road 
Vector  RouteElem; 
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i  =  0; 

while  (i  <  Route. size())  { 

RouteElem  =  Route. elementAt(i); 

if  ((Route_Elem.elementAt(road_id)  ==  rla)  ||  (Route_Elem.elementAt(road_id) 

—  rib))  { 

RouteElem.setElementAt  (roadid,  Road); 

Route. setElementAt  (i,  RouteElement); 

} 

i++; 

} 

return  Route; 

} 


/***  routeScore:  return  the  score  (function  of  threat  levels  and  distance)  of  a  route  starting  from 
Position  ***/ 


Real  route  Score  (Vector  Position,  Vector  Route) 

{ 

Real  Score  =  0; 

Vector  Edge  =  Route. element At(0); 

RoadT  Road  =  Edge.elementAt  (road  id); 
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if  (Edge.elementAt(edge_direction)  ==  “forward”) 


Score  =  (getRoadLength  (Road)  -  Position. elementAt  (road_position)); 
Else  Score  =  Position.elementAt  (road_position); 


i=  1; 

while  (i  <  Route. size  ())  { 

Edge  =  Route.  elementAt(i); 

Score  =  Score  +  ScoreRoad  (Edge.elementAt(road_id)); 
i++; 

} 

return  Score; 


/***  get_Next_Destination_Coord_KF:  return  the  position  (road  id,  road_position)  of  the  last 
point  of  the  route  ***/ 


Vector  get_Next_Destination_Coord  (Vector  Route) 

{ 

Vector  RouteElem  =  Route. elementAt  (Route. size()  -  1);  //  Final 

destinaton  at  last  element 

RoadT  Road  =  RouteElem.elementAt(roadid); 

Real  Road  Pos; 

Vector  Next_Pos; 
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//  Next_Destination,  for  key  figure,  is  always  waypoint,  so  road_position  is  either  0  or  the 
road  length 

if  (Route_Elem.elementAt(road_direction)  ==  “forward”)  RoadPos  =  getRoadLength 

(road); 

Else  Road  Pos  =  0; 


Next_Pos.insertElementAt(road_id,  Road); 
Next_Pos.insertElementAt(road_position,  Road_Pos); 
return  Next_Pos; 


/***  route_To_Safe_House:  return  the  safest  route  of  all  routes  to  all  safe  houses  (including 
origin  and  destination)  ***/ 


Vector  route_To_Safe_House  () 

{ 

Vector  Best  Route,  Route; 
Real  Min  Score  =  10000; 
Real  S; 

String  SH; 


//  Find  safest  route  for  each  safe  house,  and  select  the  shortest  of  all 
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Integer  i  =  0; 


while  (i  <  Safe_Houses_List.size())  { 

SH  =  Safe_House_List.elementAt(i); 

Route  =  get  Safest  Route  (CurrentPosition,  SH); 

S  =  route  Score  (Current  Position,  Route); 
if  (S  <  Min_Score)  { 

Min_Score  =  S; 

BestRoute  =  Route; 

} 

i++; 

} 

return  Best  Route; 

} 

/***  cnclW  P :  look  up  TerrainMap  and  return  the  endwaypoint  of  Road  ***/ 

String  endWp  (RoadT  Road) 

{ 

Vector  Terrain  Elem; 

Integer  i  =  0; 

while  (i  <  Terrain_Map)  { 
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TerrainElem  =  TerrainMap.elementAt  (i); 

if  (TerrainElem.elementAt  (roadid)  ==  Road)  return  TerrainElem.elementAt 
(end_waypoint); 

i++; 

} 

} 


/***  start WP:  look  up  TerrainMap  and  return  the  start  waypoint  of  Road  ***/ 


String  startWp  (RoadT  Road) 

{ 


Vector  Terrain  Elem; 


while  (i  <  Terrain_Map)  { 

TerrainElem  =  TerrainMap.  element  At  (i); 

if  (Terrain  Elem.elementAt  (road  id)  ==  Road)  return  Terrain  Elem.elementAt 
(start_waypoint); 

i++; 

} 

} 

/***  new_Edge:  format  an  edge  to  be  entered  in  Edges  ***/ 
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Vector  new  Edge  (RoadT  Road,  String  Start_v,  String  End_v,  Real  Score,  String  Direction)) 

{ 

Vector  Edge; 

Edge.insertElementAt(road_id,  Road); 
Edge.insertElementAt(start_waypoint,  Start_v); 
Edge.insertElementAt(end_waypoint,  End_v); 
Edge.insertElementAt(road_cost,  Score); 
Edge.insertElementAt(edge_direction,  Direction); 
return  Edge; 

} 

/***  scoreRoad:  get  the  score  (function  of  threat  level  and  distance)  of  Road  ***/ 

Real  score_Road  (RoadT  Road) 

{ 

Real  D  =  getRoadLength  (Road)  / get_Total_Length( ); 

Real  T  =  0; 

Vector  Threat  Map  Elem; 

Vector  Position; 

Real  Defeat; 

Real  Bribe; 

String  T  Type;  String  T  Size; 
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Integer  i  =  0; 


while  (i  <  Threat_Map.size())  { 

Threat_Map_Elem  =  Threat_Map.elementAt(i); 

Position  =  Threat_Map_Elem.elementAt(threat_position); 
if  (Position.elementAt  (road  id)  ==  Road)  { 

TType  =  ThreatMapElem.elementAt  (threat  type); 
TSize  =  Threat  Map  Elem.elementAt  (threat  size); 
Defeat  =  getDefeatability  (T  Type,  T  Size); 

Bribe  =  get  Brib ability  (T  Type,  T  Size); 

T  =  T  *  ( 1  -  Bribe)  *  ( 1  -  Defeat); 

} 

i++; 

} 

return  (Wd*D  +  Wt*(l  -  T)); 

} 


/***  score_Road_Section:  return  the  score  of  a  road  section.  ***/ 

/***  i  f  Ref  is  1,  score  the  section  from  RoadPos  to  start  waypoint  ***/ 

/***  If  Ref  is  2,  score  the  section  from  Road_Pos  to  end_waypoint  ***/ 

Real  score_Road_Section  (RoadT  Road,  Real  Road  Pos,  Int  Ref) 
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//  Find  D 
Real  D; 

if  (Ref  ==  1)  D.setValue  (RoadPos  /  get_Total_Length() ); 

Else  D.setValue  (( get_Length_Road  (Road)  -  Road  Pos)  / get_TotaI_Length())-, 

Real  Defeat; 

Real  Bribe; 

String  T_Type;  String  T_Size; 


//  Find  T 
Real  T  =  0; 

Vector  Position; 

Integer  i  =  0; 

while  (i  <  Threat_Map.size())  { 

ThreatMapElem  =  ThreatMap.elementAt(i); 

Position  =  Threat_Map_Elem.elemenAt(threat_position); 
if  (Position. elementAt(roadid)  ==  Road)  { 

if  (((Position.  elementAt(road_position)  <  Road_Pos)  &&  (Ref  ==  1))  || 
((Position.elementAt(roadposition)  >=  Road  Pos)  and  (Ref  ==  2)))  { 
Defeat  =  get  Defet ability  (T  Type,  T  Size); 

Bribe  =  get  Bribability  (T  Type,  T  Size); 
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T  =  T  +  Bribe  +  (1  -  Bribe)  *  Defeat; 


} 

} 

i++; 

} 

return  (Wd*D  +  Wt*(l  -  T)); 

} 

/***  getRoadLength:  Look  up  TerrainMap,  return  the  length  of  Road  ***/ 

Real  get_Road_Length  (RoadT  Road) 

{ 

Vector  TerrainMapElem; 

Integer  i  =  0; 

while  (i  <  Terrain_Map.size())  { 

Terrain_Map_Elem  =  Terrain_Map.elementAt(i); 
if  (Terrain  Map  Elem.elementAt  (road  id)  ==  Road) 

return  Terrain  Map  Elem.elementAt  (road  length); 

i++; 

} 

} 
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/***  getTotalLength:  look  up  Terrain  Map  and  get  the  sum  of  the  lenghts  of  all  roads  ***/ 

Real  get  Total  Length  (RoadT  Road) 

{ 

Vector  TerrainMapElem; 

Real  Len  =  0; 

Integer  i  =  0; 

while  (i  <  Terrain_Map.size())  { 

TerrainMapElem  =  TerrainMap.elementAt(i); 

Len  =  Len  +  Terrain_Map_Elem.elementAt  (road_length); 
i++; 

} 

return  Len; 

} 

/***  get_  Defeatability:  look  up  ThreatRiskTable  and  return  the  defeatability  given  type  and 
size  of  threat  ***/ 

Real  get  Defeatability  (ThreatT  T  Type,  String  T  Size) 

{ 

Vector  TableElem; 
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Integer  =  0; 


while  (i  <  Threat_Risk_Table.size())  { 

TableElem  =  ThreatRiskTable.elementAt  (i); 

if  ((Table_Elem.elementAt  (t_type)  ==  T_Type)  &&  (Table_Elem.elementAt 

(t_size)) 

return  Table_Element.elementAt  (defeat); 

} 

} 

/***  get_  Bribability:  look  up  Threat  Risk  Table  and  return  the  bribability  given  type  and  size 
of  threat  ***/ 

Real  get  Bribability  (ThreatT  T  Type,  String  T_Size) 

{ 

Vector  Table  Elem; 

Integer  =  0; 

while  (i  <  Threat_Risk_Table.size())  { 

Table  Elem  =  Threat  Risk  Table.elementAt  (i); 

if  ((Table_Elem.elementAt  (t_type)  ==  T_Type)  &&  (Table_Elem.elementAt 

(t_size)) 

return  TableElement.elementAt  (bribe); 
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} 


} 

/***  FUNCTIONS  in  other  libraries  ****/ 

Vector  shortest_Route_Dijikstra  (String  Start_v,  String  End  v,  set  Vertices,  set  Edges) 

{ 

//  Use  Dijikstra  algorithm  to  return  the  shortest  route  from  start_v  to  end_v 
//  Parameters: 

//  -  start_v  and  end_v:  starting  and  ending  vertices  (waypoints) 

//  -  Vertices:  Waypoints_List  +  {“start_v”,  “end_v”} 

//  -  Edges:  an  edge  is  a  directed  arc  and  we  represent  as  a  pair  (road_id,  edge_direction) 
//  -  Cost:  the  cost  are  expressed  in  the  Edges 

//  The  Dijikstra  algorithm  returns  a  sequence  of  edges  that  represents  the  shortest  path 
//  from  vertex  start_v  to  vertex  end_v 

} 

/******  PROCEDURES  key  figure  motion  manager  ****/ 

/***  route_Distance:  get  the  distance  between  Position  1  and  Position2  by  following  Route  ***/ 


Real  route_Distance  (Real  Positionl,  Real  Position2,  set  Route) 
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{ 


RoadT  Roadl  =  Position I.elementAt  (road  id); 

RoadT  Road_2  =  Position2.elementAt  (road  id); 

Real  RoadPosl  =  Position  I.elementAt  (road_position); 

Real  Road_Pos2  =  Position2.elementAt  (road_position); 

Real  Lenl  =  get_Road_Length(Road_\); 

Real  Len2  =  get_Road_Length(Road_2 ); 

//  if  posl  and  pos2  are  in  same  road,  return  their  difference  of  their  positions  (absolute 

value) 

if  (Road  l  ==  Road_2)  return  abs  (Road  Posl  -  Road_Pos2); 

//  if  they  are  not  in  same  road,  sum  the  distances  for  each  road 
Real  Distance  =  0; 

//  Sum  the  distance  from  Position  1  to  one  of  Road  l  vertices 
Vector  RouteElem  =  Route.  elementAt(O); 

if  (RouteElem.  element  At  (roaddirection)  ==  “forward”)  Distance  =  Distance  + 
RoadPosl; 

else  if  (Route_Elem.elementAt  (road_direction)  ==  “backward”)  Distance  =  Distance  + 
(Lenl  -  Road  Posl); 
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//  Sum  the  distance  from  Position2  to  one  of  Road_2  vertices 
RouteElem  =  Route.  elementAt(Route.size()  -  1); 

if  (RouteElem.  element  At  (roaddirection)  ==  “forward”)  Distance  =  Distance  + 
Road_Pos2; 

else  if  (Route_Elem.elementAt  (road_direction)  ==  “backward”)  Distance  =  Distance  + 
(len2  -  road_pos2); 

RoadT  Road; 

//  Sum  the  lengths  of  the  remaining  roads 
Integer  i  =  1 ; 

while  (i  <  Route. size()  -  2)  {  //  Note:  if  posl  and  pos2  are  not  in  same 

road,  then  route  size  is  at  least  2 

RouteElem  =  Route.  elementAt(i); 

Road  =  RouteElem.elementAt(roadid); 

Distance  =  Distance  +  getRoadLength  (Road); 

} 

return  Distance; 

} 

/***  check  if  Position  is  a  safe  house  position  ****/ 

Boolean  is_Safe_House_Position  (set  Position) 

{ 
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String  Safe_House; 


Vector  SafeHousePositions; 

Vector  SHCoord; 

Integer  i  =  0; 

while  (i  <  Safe_Houses_List.size())  { 

SafeHouse  =  SafeHouseList.elementAt(i); 

Safe  House  Positions  =  get_Safe_House_Coordinates  (Safe  House); 

J  =  0; 

while  (j  <  Safe_House_Positions.size())  { 

SHCoord  =  Safe_House_Position.elementAt(j); 

if  (((SHCoord.elementAt(roadid)  ==  Position.elementAt(roadid))  && 

(SH_Coord.elementAt(road_position)  == 

Position.elementAt(road_position)))  return  true; 

} 

i++; 

} 

return  false; 

} 

/***  get_Safe_House_Coordinates:  given  a  Safe_House,  return  a  list  of  possible  ways  to  express 
its  position  ***/ 
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Vector  get_Safe_House_Coordinates  (String  Safe  House) 

{ 

Integer  i  =  0; 

Vector  SafeHousePosition; 

Vector  PositionList; 

while  (i  <  Terrain_Map.size())  { 

//  check  if  safe  house  is  a  start_waypoint  of  a  road  — >  position  is  (road,  0) 

TerrainMapElem  =  TerrainMap.elementAt(i); 

if  (Terrain_Map_Elem.elementAt(start_waypoint)  ==  Safe_House)  { 

SafeHousePosition.insertElementAt  (roadid, 

Terra_Map_Elem.elementAt(road_id)); 

SafeHousePosition.insertElementAt  (road_position,  0); 

PositionList.addElement  (Safe  House  Position); 

} 

//  check  if  safe  house  is  a  end  waypoint  of  a  road  — >  position  is  (road,  road 

length) 

if  (Terrain_Map_Elem.elementAt(end_waypoint)  ==  safe_House)  { 
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SafeHousePosition.insertElementAt  (roadid, 

Terrain_Map_Elem.elementAt(road_id); 

SafeHousePosition.insertElementAt  (road_position, 

Terrain_Map_Elem.elementAt(road_length)); 


PositionList.addElement  (SafeHousePosition); 

} 

i++; 

} 

return  PositionList; 

} 


/***  find  Next  Position:  Given  a  distance,  a  position,  and  a  route,  the  function  returns  the  next 
position  ***/ 

Vector  find_Next_Position  (Real  Distance,  Vector  Position,  Vector  Route) 

{ 

Real  D  =  Distance; 

Vector  Cur  Pos  =  Position.copy  (); 

Vector  Cur  Route  =  Route. copy  (); 

Vector  Cur  Route  Elem,  Next  Route  Elem; 


RoadT  Cur  Road; 
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Real  CurRoadPos; 

String  CurDirection; 

Real  Len; 

while  (D  >  0)  { 

CurRouteElem  =  CurRoute.  element  At  (0); 

Cur  Direction  =  CurRouteElem.elementAt  (roaddirection); 

CurRoad  =  CurPos.elementAt  (roadid); 

Cur  Road  Pos  =  Cur  Pos.elementAt  (road_position); 

if  (Cur  Direction  ==  “forward”)  { 

Len  =  getRoadLength  (Cur  Road)); 
if  ((Cur  Road  Pos  +  D)  >  Len)  { 

D  =  Cur  Road  Pos  +  D  -  Len;  //  remaining  D  after 

reaching  vertex 

//  Move  to  next  coordinate,  update  Cur  Route  and  Cur_pos 
Next_Route_Elem  =  Cur  Route. element At  (1); 
Cur_Pos.setElementAt  (road_id,  Next_Route_Elem.elementAt 

(roadid)); 
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CurPos.setElementAt  (road_position,  getRoadStart 

(N  ext_Route_Elem)) ; 

CurRoute.removeElementAt(O); 


} 

Else  { 

D  =  0; 

Cur  Pos.setElementAt  (road_position,  CurRoadPos  +  D); 

} 

} 

Else  if  (Direction  ==  “backward”)  { 
if  ((D  >  Cur  Road  Pos)  { 

D  =  D  -  Cur  Road  Pos; 


(road_id)); 


(N  ext_Route_Elem)) ; 


//  Move  to  next  coordinate,  update  CurRoute  and  Cur_pos 
Next_Route_Elem  =  CurRoute.  element  At  (1); 
CurPos.setElementAt  (roadid,  NextRouteElem.  element  At 

CurPos.setElementAt  (road_position,  getRoadStart 

CurRoute .  remo  veElement At(  0) ; 
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} 


Else  { 

D  =  0; 

CurPos.setElementAt  (road_position,  CurRoadPos  +  D); 

} 

} 

} 

return  Cur  Pos; 

} 

/***  getRoadStart:  given  a  route  element,  return  0  if  direction  is  forward  or  the  route  length  if 
backward  ***/ 

Real  get  Road  Start  (Vector  RouteElem) 

{ 

if  (RouteElem. elementAt  (road  direction)  ==  “forward”)  return  0; 
else  if  (RouteElem. elementAt  (road_direction)  ==  “backward”) 

return  getRoadLength  (RouteElem. elementAt  (road  id)); 

} 


void  update_Truth_Table_Position  (String  Actor,  Vector  Position) 
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{ 


Vector  TableElem; 

Vector  Position; 

RoadT  Road  =  Position.  elementAt  (road  id); 

Real  RoadPos  =  Position.  elementAt  (road_pos); 

i  =  0; 

while  (i  <  Ground_Truth_Table.size())  { 

Table  Elem  =  GroundTruthT able. elementAt  (i); 
if  (Table  Elem. elementAt  (actor_name)  ==  Actor)  { 

Position  =  Table  Elem. elementAt  (actor_position); 
Position.setElementAt  (road  id,  Road); 
Position.setElementAt  (road_position,  Road  Pos); 
TableElem.setElementAt  (actor_position,  Position); 
GroundTruthTable.setElementAt  (i,  Table  Elem); 
break; 

} 

} 

} 
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/*****  PROCEDURES  threat  analyzer  *****/ 


void  processAMessage  (Vector  Message,  Vector  TMap) 

{ 

i  =  0; 

while  (i  <  T_Map.size)  { 

TMapElem  =  TMap.elementAt(i); 

if  (Message. elementAt  (threat_id)  ==  T_Map_Elem.elementAt  (threat_id))  { 

T_Map_Elem.elementAt  (threat_position)  =  Message. elementAt 

(threatposition); 

T  Map  Elem.  elementAt  (position_range)  =  0; 

T_Map.setElementAt  (i,  T_Map_Elem); 
break; 

} 

i++; 

} 

} 

/****  PROCEDURES  threat  sensor  ****/ 


Real  distance  (Vector  Position-!,  Vector  Position2) 

{ 
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Vector  Rout z=  get_Shortest_Route  (Positionl,  Position2); 
return  route  Distance  (Positionl,  Position2,  Route); 

} 

void  sendMessage  (ThreatT  Threat,  Vector  Position) 

{ 

Vector  Message; 

Message. insertElementAt  (threat_id,  Threat); 

Message. insertElementAt  (threat_position,  Position); 

Threat_Sensor_Data.addElement  (Message); 

} 

Vector  get  Shortest  Route  (Vector  Positionl,  Vector  Position2) 

{ 

RoadT  Roadl  =  Position I.elementAt  (roadid); 

RoadT  Road_2  =  Position2.elementAt  (road  id); 

Real  Road  Posl  =  Positionl. elementAt(road_position); 
Real  Road_Pos2  =  Position2.elementAt(road_position); 
Real  RoadLenl  =  get_Road_Length(Koad_\); 

Real  Road  Lenl  =  get_Road_Length( Road  l); 

Vector  RouteElem; 
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//  check  if  posl  and  pos2  are  in  the  same  road,  if  yes,  the  route  is  the 


if  (Roadl  ==  Road_2)  { 

RouteElem.insertElementAt  (road  id,  Road  l); 

if  (Road_Pos2  >=  RoadPosl)  Route  Elem.insertElementAt  (roaddirection, 

“forward”); 

Else  Route  Elem.insertElementAt  (road  direction,  “backward”); 

Route. addElement  (RouteElem); 
return  Route; 

} 

//  if  they  are  not  in  same  road,  get  the  4  vertices 
String  SI  =  startWp  (Road_l); 

String  El  =  endWp  (Road_l); 

String  S2  =  startWp  (Road_2); 

String  E2  =  endWp  (Road_2); 

//  Buid  Vertices  and  insert  two  more  vertices  corresponding  to  posl  and  pos2 
Vector  Vertices  =  Waypoints_List.copy  (); 

Vertices. addElement  (“start_v”); 
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Vertices. addElement  (“end_v”); 

//  Build  Edges,  insert  new  edges  for  Position  1  and  Position2 

Edges. addElement  (New_Edge  (rla,  SI,  “start_v”,  Road_Posl,  “forward”); 

Edges. addElement  (New_Edge  (rla,  ”start_v”,  SI,  Road_Posl,  “backward”); 

Edges. addElement  (New_Edge  (rib,  El,  “start_v”,  Road_Lenl  -  Road_Posl, 

“forward”); 

Edges. addElement  (New_Edge  (rib,  ”start_v”,  El,  Road_Lenl  -  Road_Posl, 

“backward”); 

Edges. addElement  (New_Edge  (r2a,  S2,  “end_v”,  Road_Pos2,  “forward”); 

Edges. addElement  (New_Edge  (r2a,  ”end_v”,  S2,  Road_Pos2,  “backward”); 

Edges. addElement  (New_Edge  (r2b,  E2,  “end_v”,  Road_Len2  -  Road_Pos2,  “forward”); 

Edges. addElement  (New_Edge  (r2b,  ”end_v”,  E2,  Road_Len2  -  Road_Pos2, 

“backward”); 

Vector  Route  =  shortest  Route  Dijisktra  (“start_v”,  “end_v”,  Vertices,  Edges); 

//  Replace  rla  =  road_l,  rib  =  road_l,  r2a  =  road_2,  r2b  =  road_2 

Integer  i  =  0; 

while  (i  <  Route. size())  { 

RouteElem  =  Route.  elementAt(i); 
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if  ((Route_Elem.elementAt(road_id)  ==  rla)  ||  (Route_Elem.elementAt(road_id) 

==  rib))  { 

RouteElem.  setElementAt  (roadid,  Road  l); 

Route. setElementAt  (i,  RouteElem); 

} 

if  ((RouteElem.elementAt(roadid)  ==  r2a)  or  (RouteElem.elementAt(roadid) 

==r2b)){ 

Route  Elem.  setElementAt  (road  id,  Road_2); 

Route. setElementAt  (i,  Route  Elem); 

} 

i++; 

} 

return  Route; 


} 


Boolean  randomBinary  (Real  Success  prob) 

{ 


if  (w()  <=  Success_prob)  return  “true”; 
Else  return  “false”; 


} 


/***  functions  defined  in  other  places  ***/ 
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//  In  Key  Figure  Route  Planner 

Real  get_Road_Length  (RoadT  Road)  {} 

Vector  shortestRouteDijikstra  (String  Start_v,  String  Endv,  set  Vertices,  set  Edges)  {} 


/***  functions  in  other  libraries  ****/ 


Real  u() 

{ 


//  Random  variable  with  unifonn  distribution:  return  a  number  between  0  and  1  with 
uniform  distribution 


//  Look  algorithms  or  library  for  random  number  generation 


} 

/***  PROCEDURES  threat  phone  caller  ****/ 

/***  functions  defined  in  other  places  ***/ 


//  In  Threat  Sensor 

Boolean  randomBinary  (Real  Success  prob)  {} 

void  send  Message  (ThreatT  Threat,  Vector  Position)  {} 
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/***  PROCEDURES  good  guys  route  planner  ***/ 


/**  lost  Target  Position  lost  the  position  of  the  target  if  the  range  includes  the  vertices  of  the 
road  **/ 


Boolean  is_Position_Accurate  (Real  Pos  Range) 

{ 

RoadT  Road  =  TargetPositionEstimate.elementAt  (road  id); 

Real  RoadPos  =  TargetPositionEstimate.elementAt  (road_position); 
Real  RoadLen  =  getRoadLength  (Road); 


return  ((TargetPositionRange  <=  RoadPos)  &&  (TargetPositionRange  <= 
(Road  Len  -  Road  Pos)); 

} 


/**  is  Target  Captured  checks  if  the  position  of  the  distance  to  target  is  within  the  capture  range 

**/ 


Boolean  is_Target_Captured  (Vector  Position) 

{ 

Targ  Position  =  get_Truth_Table_Position  (“key  figure”); 


Real  D  =  distance  (Position,  Targ  Position); 
return  (D  <=  Capture  Range); 
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} 


/**  get_Truth_Table_Position  look  up  Ground  Truth  Table  for  the  real  position  of  Actor  **/ 


Vector  get_Truth_Table_Position  (String  Actor) 

{ 

Vector  TableElem; 

Integer  i  =  0; 

while  (i  <  Truth_Table_Position.size())  { 

Table  Elern  =  Ground  Truth  Table.elementAt(i); 

if  (TableElem.elementAt  (actorname)  ==  Actor)  return 
Table_Element.elementAt(actor_position) 

i++; 

} 

} 


/***  functions  defined  in  other  modules  ***/ 


//  Threat  Sensor 

Vector  get  Shortest  Route  (Vector  Position! ,  Vector  Position2) 
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//  In  Key  Figure  Route  Planner 

Real  get_Road_Length  (RoadT  Road)  {} 


/***  functions  in  other  libraries  ****/ 


Real  randjnt  (Int  a,  Int  b) 

{ 


//  Random  variable  that  generates  a  random  integer  between  the  interval  [a,  b] 

//  e.g.  rand_Int  (0,  4)  returns,  with  equal  probability,  one  of  the  numbers:  0,  1,2,  3,  4. 


} 


/***  PROCEDURE  good  guys  motion  manager  ****/ 

/***  FUNCTIONS  defined  in  other  modules  ***/ 


//  Key  Figure  Motion  Manager 

Real  route_Distance  (Real  Positionl,  Real  Position2,  set  Route)  {} 

Vector  find_Next_Position  (Real  Distance,  Vector  Position,  Vector  Route)  {} 
void  update_Truth_Table_Position  (String  Actor,  Vector  Position)  {} 


//  Threat  Sensor 

Real  distance  (Vector  Positionl,  Vector  Position2)  {} 
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/***  PROCEDURES  SENSOR  READER  ***/ 


void  decay  (Vector  Position  Range) 

{ 

TargetPositionRange  =  TargetPositionRange  +  DecayRate; 

} 

/***  PROCEDURES  TARGET  SENSOR  ****/ 

/***  functions  defined  in  other  modules  ***/ 


//  Key  Figure  Motion  Manager 

Boolean  is_Safe_House_Position  (set  Position)  {} 


//  Threat  Sensor 

Real  distance  (Vector  Position-!,  Vector  Position2)  {} 

Boolean  randomBinary  (Real  Success  prob)  {} 


//  Good  Guys  Motion  Manager 

Vector  get_Truth_Table_Position  (String  Actor)  {} 


/***  PROCEDURES  target  phone  caller  ****/ 

/***  functions  defined  in  other  modules  ***/ 
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//  Threat  Sensor 

Real  distance  (Vector  Position-!,  Vector  Position2)  {} 

Boolean  randomBinary  (Real  Success  prob)  {} 
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